TSimpleGraph extended

Please post bug reports, feature requests, or any question regarding the DELPHI AREA products here.

TSimpleGraph extended

Postby Stefan » September 28th, 2004, 11:26 am

L.S.

Some of us might have run into problems with TSimpleGraph.
Not so much in the sense that the code is faulty but in the sense that it is
generally limited to simple graph theory.
Some people have asked for extentions on TSimpleGraph, but this, quite naturally, is not done, because of the fact that it is a simple graph component not an extended.
Apart from that, Kambiz is limited in his time, he cannot put drasticilly more time in extending TSimpleGraph. Which is understandable.

However, I do not see how this should limit the development of an otherwise great component. I would like to discuss several possibilities with you all as to how we could extend TSimpleGraph's development.

In short:

Anyone up for joining me in re-designing TSimpleGraph?

- A node designer, so that no-one will ever have to ask for a shape again
- Polylines, so that we can tidy up those big graphs
- Automatic routing for polylines, so that we don't have to put too much work into tidying up big graphs :)

- Your idea here...?

Kind regards,
Stefan
User avatar
Stefan
Moderator
Moderator
 
Posts: 128
Joined: September 27th, 2004, 9:40 am
Location: Tilburg, The Netherlands

TSimpleGraph Extended

Postby pavel » September 29th, 2004, 2:50 pm

Hi Stefan,

I have been thinking about extending TSimpeGraph, too.
I have already made something.
I used simplegraph as a sort of CASE/business process designer GUI.

That is why I have extended/tweaked Simplegraph so that:
- graph is saved in xml format
- Node property editor can handle attached data
- data processing based on graph

I have also found that shapes based on open SVG format should not be so paramount task. IMHO this will enable to use simplegrah for applications like UML authoring, web publishing, workflow design, CASE etc.

Well I am able and willing to talk and to participate in extending simplegraph.
Pavel
pavel
Active Member
Active Member
 
Posts: 15
Joined: September 29th, 2004, 2:39 pm
Location: Czech Republic; Prague

Postby Stefan » October 6th, 2004, 9:18 am

Hi Pavel,

I like your ideas. I especially like your idea regarding nodes handling attached data. This would be a very nice feature.

I've shortly discussed the options with Kambiz and he's ok with setting up a sourceforge project. This would enable us all to extend and enhance SimpleGraph *and* make it available for public download.

I think that we should set up a list of things we would want to change / enhance in SimpleGraph, and a more general goal as to where we want to go with regard to SimpleGraph.

We (or better yet, Kambiz) should decide on a License model which we will use for the sourceforge project (I am all for BSD, MPL or LGPL, in that specific order).

That's it for now, please let me know what you think.

Greets,
Stefan
User avatar
Stefan
Moderator
Moderator
 
Posts: 128
Joined: September 27th, 2004, 9:40 am
Location: Tilburg, The Netherlands

Help with Simplegraph Extended

Postby Kim_Bracknell » October 7th, 2004, 2:02 am

Hi Kambiz,
Although I am probably not experienced enough with helping code any extensions to Simplegraph, I can assist with usability testing if necessary.
Cheers,
Kim.
Kim_Bracknell
Member
Member
 
Posts: 1
Joined: October 7th, 2004, 2:00 am
Location: Perth, Western Australia

Simplegraph Extended

Postby pavel » October 7th, 2004, 8:51 am

It seams that Extended Simplegraph starts to take shape.

Sourceforge is IMHO good platform while it is very visible site and a good way, how to publicize our work.

Regarding licence I have no preferences, while I think that all mentioned licenses guarantees open source way.

Regarding goals: I agree that this is very important to define it in the beginning.
My understanding of things is, that when technology leaves laboratory, further development is dictated more by applications.
I have used Simplegraph to create GUI for design of Business processing engine, I also thought about using it for Case like tool for XML-SQL DDL conversions.
As I have already mentioned I have extended Simplegraph so, that to objects (graph nodes and edges) can be attached complex structure and even processing code.
Both applications will require to attach graphical objects (shapes) to represented data objects.
I have already sent to Kambiz some alpha/beta version of it.

That is why I propose following extensions:
- Library of shapes (preferably in open SVG format), meaning that user can define new shapes, ideally using SVG enabled editor. Some web container of already defined groups of shapes will be also fine (something like MS Visio galleries)
- Configurable Node and Link property editor, I already have some useable code that I am ready to donate to this project.,

And at last, but not least, thanks to Kim for testing offer, if the project will be launched it will be very valuable contribution.

Pavel.
Last edited by pavel on October 7th, 2004, 9:40 am, edited 1 time in total.
Pavel
pavel
Active Member
Active Member
 
Posts: 15
Joined: September 29th, 2004, 2:39 pm
Location: Czech Republic; Prague

Postby pavel » October 7th, 2004, 9:05 am

BTW.

I supposed that when "Notify me when reply" is enabled, then I will receive emails. But I did not.

Is there any option, how to get forum messages by email? Or is it some incorrect setting of my profile?

It is not much convenient to check new posts only through web.
Pavel
pavel
Active Member
Active Member
 
Posts: 15
Joined: September 29th, 2004, 2:39 pm
Location: Czech Republic; Prague

Postby Stefan » October 7th, 2004, 10:47 am

I would like to propose the MPL license ( http://www.mozilla.org/MPL/MPL-1.1.html or http://www.mozilla.org/MPL/mpl-faq.html ) as this serves the OpenSource development of the component right but still enables closed source applications.
As Kambiz is the "father" of SimpleGraph I think the choice is entirely his.

As we seem to all agree on SourceForge I think this would be the way to go. It indeed gives good visibillity and serves as a good platform for OpenSource development.
To set up a project on SourceForge we need to have at least decided on general goals and a license.

I too think that how a component is used dictates future development. I have used SimpleGraph in much the same way as Pavel has. I have used SimpleGraph to represent State-flow diagrams for industrial weighing processes. The abillity to hook data and code to nodes is IMHO a big step forward. Also the Node-designer and a gallery much the same as in MS Visio is good. I have already started development on this and will report progress.

Pavel, as you have already implemented an XML save option I too think that it will be quite easy to convert this to the SVG format.

The to-do list so far:

1. Node designer
2. SVG enable the node- and graphdesigner
3. Support for PolyLine LinkNodes
4. A gallery of nodes
5. Make nodes and links data-aware and allow for datastructures and code to be hooked to it.

Pavel, regarding (5) and attaching code, perhaps it is a good idea to create an eventdriven system for the Nodes (OnEnter, OnCalculate, OnExit)?

I know it's a long shot, but perhaps people are interested in a COM-object model for the component, or is this too far-fetched?

Lastly, thanks to Kim for his kind offer.

Cheers,
Stefan
User avatar
Stefan
Moderator
Moderator
 
Posts: 128
Joined: September 27th, 2004, 9:40 am
Location: Tilburg, The Netherlands

Postby pavel » October 7th, 2004, 12:35 pm

Comments to goals:
It seems that so far SimpleGraph usage can be strong in GUI layer upon workflow/dataflow applications and engines.
This also can define a goal of Simplegraph Extended development.
It is also possible to go "Visio" way ie. to try to create Drawing editor, but I am a little sceptical about it, while we will directly compete with well established open source and commercial projects, and it will be far more difficult to deliver some real added value (compared say to Dia, JGraph or Visio).
Nevertheless we can utilize these projects and use them as optional gallery shape editors.

IMHO orientation to industry/business processes is more interestig and promissing target.

Comments to to-do list:
1-2 I think that gallery and svg "view" is higher in priority than svg designer/editor. As I have mentioned above, there are many running SVG projects, some of them can be found at http://www.w3.org/Graphics/SVG/SVG-Implementations.
Use case for gallery designer than can be:
1. Design symbol in your favorite SVG editor.
2. Place svg in SGraph gallery folder under some distinguished name
3. Use it in your diagrams.
4. Consider publishing it as a part of SGraph project.

Event driven mechanism:
I am not sure about extending events. As I view SGraph mainly as an open front end to workflow/business process engines, I think that event proccessing is engines job. I have in mind data and time related events like OnTime, OnReceive, OnRespond, OnHold, OnPrint, OnStateChange ...
Another story are application events, that, Stefan has probably in mind.

To do list and priorities, inevitably, will change according to inteded applications. Seems that workflow needs dictates following roadmap:
1. SVG enabled SGraph (use case: open svg file, click on canvas, see the symbol)
2. XML graph save format (although I already have one implemented, I think that it should be revised).
3. Highly configurable node/link property editor that will enable to create new editors for different data structures without the need of program recompilation.
4. Gallery mechanism

Your comments?
Pavel
pavel
Active Member
Active Member
 
Posts: 15
Joined: September 29th, 2004, 2:39 pm
Location: Czech Republic; Prague

Postby Stefan » October 7th, 2004, 1:43 pm

I think that we should claerly define whether we are creating a component(package) or an entire application. The Visio way would indeed mean creating an entire application.
I think the strength of SimpleGraph up until now has been that it is simply a component and people could implement whatever they wanted on top of that / behind it and even fully integrate it within their own applications.
Going application-style (like Visio) would make that process harder. In short: you're right :)

Using external SVG editors to create GraphNodes is a good idea, this should save us the trouble of having to design it ourselves. Though, in time I think this could be a good idea since one might want to integrate an editor into the application one is building and having to have an external program, in that case, is not so pretty.

About the events, you are right, I was getting a little over enthousiastic, this is ofcourse the engines job.

With regard to the to-do list:

2: Do you intend to use your own XML format or SVG?
3: I'm sorry, I'm not sure I understand. Could you give an example?

And I have seen some requests here for PolyLine support. I too would like to see this implemented. I already have some ideas with regard to automatic routing of the lines.

All 'n' all I think we're getting there. Now if only Kambiz could decide on the license..... :)

Cheers,
Stefan
User avatar
Stefan
Moderator
Moderator
 
Posts: 128
Joined: September 27th, 2004, 9:40 am
Location: Tilburg, The Netherlands

Postby pavel » October 7th, 2004, 8:18 pm

Well, my intention is to create open source application using SGraph.
But I do not want to propose that SGraph and this application should be merged, I think that SGraph should be independent as well as other core technologies like XML parser, Internet related libraries ...

Maybe I will better express myself saying that as a part of developing application, SGraph will be enhanced, too.
I agree with statement that SGraph should remain self standing component, integrate able to other applications.

I have had in mind a scheme of JGraph, where there is core technology (SGraph in our case) and growing number of more or less loosely connected application projects that may or may not be part of JGraph project.
In our case such applications can be Work flow, State flow, Schema Editor, Case tool ...

SVG/XML format... well it is not so easy to explain, what I mean, but I will try.
Matter of factly there are, in my understanding, two problems:
1. How to ease and generalize the way of creating new new graphical objects or primitives (for example Kambiz has added polygon)
2. How and in which format to save graph consisting from these primitives.

I will try to address them separately and to give a proposal at the same time.
New graphical objects will be created in SVG editor, for example nice looking picture of computer (or better reused already existing one). This picture will be placed in library and inserted as grapn node, similarly to placing circles.

Second problem is format of the whole graph. We have object (say computer) and data attached to it (processor type, serial number, manufacturer, computer name ...). Another type of graph can be business process described in BPL XML language, yet another type will be state or dataflow, or class diagram in XMI.
So that is why I think about several XML formats that will integrate GUI and data. Some of them can be proprietary. For example data
<Computer>
<Processor>Athlon XP</Processor>
</Computer>
can be merged to:
<Computer xgraph:glyph=”computerpicture.svg” xgraph:left=”20” xgraph:top=”100” xgraph:bkcolor=”red”>
<Processor>Athlon XP</Processor>
</Computer>
meaning that on xy position 20;100 should be displayed computer glyph on red background, and node property dialog should support editing of processor element value (Athlon XP).
This can be achieved by xml/template mechanism like xml + xslt = html processing, options are many. Similarly data aware node property dialog can be done - here conceptual models are XForms or MS InfoPath.
Pavel
pavel
Active Member
Active Member
 
Posts: 15
Joined: September 29th, 2004, 2:39 pm
Location: Czech Republic; Prague

Postby Stefan » October 7th, 2004, 9:15 pm

I like your ideas.
I'm not really up to date with xml and xslt so I'll have to take your word for it. I will be reading into the subject however, so that I can help.

I've looked into SVG and found some things that might cause us problems: since SVG files can contain non-polygonal drawings how would we be able to connect LinkNodes it? And I believe SVG files can even contain macro's (?) for animation, I don't suppose this is needed in a graph. Ofcourse these are just some of the problems we might run into using SVG.
My question is: what is the problem with setting up our own format? All we basicilly need is to be able to define a polygon, set some colors and a background property, or is it?
User avatar
Stefan
Moderator
Moderator
 
Posts: 128
Joined: September 27th, 2004, 9:40 am
Location: Tilburg, The Netherlands

Postby pavel » October 7th, 2004, 10:09 pm

Hi Stefan,
I agree that to fully implement SVG is out of scope, but still we can start with minimal subset that works with objects like line, circle, trace. Other more tricky stuff like gradient fills can be added later "on demand".
Technically speaking during XML processing we will just skip not implemented features.

Regarding big graphs, we can also consider drill-down ie. mechanism that will link several graphs or implement a tree of graphs.

Now, I am not sure that I understand meaning of polyline and tidying of big graphs. I probably misinterpreted it. Can you explain it in more detail? Thanx.

Cheers
Pavel
pavel
Active Member
Active Member
 
Posts: 15
Joined: September 29th, 2004, 2:39 pm
Location: Czech Republic; Prague

Postby Stefan » October 7th, 2004, 11:44 pm

As it is getting late and marihuana is legal here my mind is not as clear as it was before, but still, I will try to explain. ;)

The Polyline should be a TGraphLink descendant which simply is a TGraphLink with corners. This way the lines can be made so that they do not cross over nodes or even other lines (if this is necessary).
My idea for automatic routing is to create a gridded virtual represantation of the graph and then create a "bubble" space around the nodes, then use a shortest-path algorightm (A*?) to find the connecting node over the "virtual grid" avoiding nodes and their respective "bubbles" of space around them so that the (poly)line will not cross over them.

This way (using routed polylines) bigger graphs will be tidier (better readable) than when the lines (as it is now) run all over the screen, straight through other nodes and lines.

Skipping not implemented parts is a good idea, could and should have though of that... but that still leaves us (when implementing ie a Line, Square and circle part for instance) with the following, suppose this is your SVG drawing:

[_]---()

[_] being a square, --- being a single line and () being a circle. how would we implement TGraphLink (regardless of it being a polyline) to connect to it? Would we build a square around it and connect to that, or should we be able to connect to all individual parts (the square, line and circle)?

Cheers,
Stefan
User avatar
Stefan
Moderator
Moderator
 
Posts: 128
Joined: September 27th, 2004, 9:40 am
Location: Tilburg, The Netherlands

Postby pavel » October 8th, 2004, 1:44 pm

Aha, that's clear, now.

I like your grid idea. It can minimize problem complexity.
Still it will not be easy task.

Another approach (also not easy) can be sort of multidimensional optimization problem.
Shortest distance can be only one optimization parameter.
Another one and probably with higher weight can be:
- minimize number of edge (line, connectors) crossings
- minimize number and lengths of node (circle, picture) crossings

In this case algoritm can be quite different and based on configureable number of iterations. Something like
- create initial state
- calculate optimization criteria for whole graph (or part of it)
- make pseudo random change
- calculate optimization criteria for new state
- accept if better, omit if worse
- make pseudo random change...

But maybe I speculate too much. Finding the shortest way in grid while avoding nodes should work fine and I definitely like the idea.

How to handle connection of links and nodes is also a good question.
When I think about it, we have following possibilities:
1. As you proposed: drawing a filled square. This will have several advantages. There will just 4 connector points, easily calculated from rectangle region boundaries. This also solves problem of visibility using zbuffer, when links are by default drawn firts, nodes next. Zbuffer can be changed by Bring to front/back functions.
2. As you proposed: to define points for each base object. Here we can later run into problem in the case of complex pictures.
3. To define such points declaratively as a part of symbol design. For example picture of 8 port network hub can have defined 8 points on the picture.

I think that we can start with rectangle with 4 or 12 points (ie. 3 points on each rectangle side, in the middle and 1/4th). Later it can be extended to user defined connector nodes.
Pavel
pavel
Active Member
Active Member
 
Posts: 15
Joined: September 29th, 2004, 2:39 pm
Location: Czech Republic; Prague

Postby Stefan » October 8th, 2004, 2:38 pm

We could use the AStar shortest path algorithm with manhattan-distance (or whatever they call it these days) over a "grid" that is built up of points that are either valid (nothing there) or invalid (a node there), and can indeed add extra weight to the crossing of other lines and the amount of corners it has to make before it gets to the end-node.
We could make it so that the user enters the amount of weight it wants to give to the three "parameters":

- path length,
- line crossing,
- and corners.

That way the (end)user can control everything.

I have dropped the development of the SVG-NodeDesigner for now (as we both agreed it has a low priority) and have picked up the development of the pathfinding algorithm..

The linking of nodes:
Eventhough I proposed the squared box, I'm not really in favor of it since it does not really improve SimpleGraph, as this can already be done using the background property of a node.

If every node would only consist of a polygon structure (be it a mad one :) ) we could use the existing polygon node to determin where to connect, but I agree that this is probably not always going to be the case.
The last option is IMHO the best one. I believe that this is how Visio handles this problem and this is a "nice" way of doing it. Though, how would you define these "connection-points" in an SVG drawing? Does it allow for that?

Cheers,
Stefan
User avatar
Stefan
Moderator
Moderator
 
Posts: 128
Joined: September 27th, 2004, 9:40 am
Location: Tilburg, The Netherlands

Next

Return to DELPHI AREA Products

Who is online

Users browsing this forum: No registered users and 1 guest

cron