DELPHI AREA :: View topic - TSimpleGraph extended

through

[^/[Print]\]

DELPHI AREA -> DELPHI AREA's Products

#1: TSimpleGraph extended Author: Stefan, Location: Belgium, Antwerp

Posted: 28/09/04 11:26
—
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 Smile

- Your idea here...?

Kind regards,
Stefan

#2: TSimpleGraph Extended Author: pavel, Location: Czech Republic; Prague

Posted: 29/09/04 14:50
—
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.

#3: Author: Stefan, Location: Belgium, Antwerp

Posted: 06/10/04 09:18
—
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

#4: Help with Simplegraph Extended Author: Kim_Bracknell, Location: Perth, Western Australia

Posted: 07/10/04 02:02
—
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.

#5: Simplegraph Extended Author: pavel, Location: Czech Republic; Prague

Posted: 07/10/04 08:51
—
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 07/10/04 09:40; edited 1 time in total

#6: Author: pavel, Location: Czech Republic; Prague

Posted: 07/10/04 09:05
—
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.

#7: Author: Stefan, Location: Belgium, Antwerp

Posted: 07/10/04 10:47
—
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

#8: Author: pavel, Location: Czech Republic; Prague

Posted: 07/10/04 12:35
—
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?

#9: Author: Stefan, Location: Belgium, Antwerp

Posted: 07/10/04 13:43
—
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 Smile

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..... Smile

Cheers,
Stefan

#10: Author: pavel, Location: Czech Republic; Prague

Posted: 07/10/04 20:18
—
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.

#11: Author: Stefan, Location: Belgium, Antwerp

Posted: 07/10/04 21:15
—
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?

#12: Author: pavel, Location: Czech Republic; Prague

Posted: 07/10/04 22:09
—
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

#13: Author: Stefan, Location: Belgium, Antwerp

Posted: 07/10/04 23:44
—
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. Wink

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

#14: Author: pavel, Location: Czech Republic; Prague

Posted: 08/10/04 13:44
—
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.

#15: Author: Stefan, Location: Belgium, Antwerp

Posted: 08/10/04 14:38
—
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 Smile

) 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

#16: Author: pavel, Location: Czech Republic; Prague

Posted: 08/10/04 15:50
—
I forgot that rectangle connector option is already implemented, you are right. This will not be enhacement.
I am not an expert on svg, my way is learning "on the fly". We will have to check it and if there is nothing appropriate, maybe to enhance svg a little.
Cheers

#17: Author: Kambiz, Location: Tehran, Iran

Posted: 08/10/04 16:43
—
Hi guys,

I'm glad to see you so active here.

I too agree with the MPL license. And, please just feel free to do whatever you want regarding the component.

Good luck,
Kambiz

#18: Author: Stefan, Location: Belgium, Antwerp

Posted: 10/10/04 16:43
—
Hi guys,

The sourceforge project is now pending. We will probably get an answer this week. I'll report any progress in the process.

Pavel, I'll have to get back to you on the SVG connection points. I'm a bit busy the next day or two so I'll probably have my questions ready after that.

Cheers,
Stefan

#19: Author: Stefan, Location: Belgium, Antwerp

Posted: 12/10/04 08:23
—
Hello all,

Good news! The project has been approved for SourceForge, it can now be found on http://sourceforge.net/projects/extgraph/
and the webspace is available at http://extgraph.sourceforge.net (though there's no site there yet).

I think it would be wise to keep the discussion here for a while though, up until we are beyond the planning stage.
I'll upload the latest version of TSimpleGraph for the time being.

More good news, development for the polylines and routing is taking shape. It is quite a daunting task however, but we did expect that.

Cheers,
Stefan

#20: Author: Stefan, Location: Belgium, Antwerp

Posted: 13/10/04 11:48
—
More good news...

I've finished the routing algo, it works much the same way as I described it. I'll upload a couple of screenshots later today...
It adds a variable ammount of weight to the changing of direction, it adds weight to the crossing of another GraphLink and it avoides GraphNodes and their bubbles (which are variable in size, depending on the user's settings).

Cheers,
Stefan

#21: Screenshots Author: Stefan, Location: Belgium, Antwerp

Posted: 14/10/04 08:00
—
Here are the screenshots...
The red line is the path it has to find from node (0,0) to (50,30) which is somewhere in the lower-right regions of the "grid" (as you can see)...

#22: SVG Author: pavel, Location: Czech Republic; Prague

Posted: 17/10/04 19:30
—
Hi Stefan,
I have made some prototype, too.
I have extended Simplegraph so that you can select svg file and it is parsed and partially displayed.
Implemented are:
- path in the from lines
- rectangles
SVG file can be edited so that XML editor is called.

I think that we should co-ordinate development a little, now.

Pavel

#23: extgraph progress Author: Stefan, Location: Belgium, Antwerp

Posted: 18/10/04 12:12
—
Hello all,

Pavel, as you know you have been added to the SF project. Also, coordination will be a lot easier now as we can use all of SF's project-management capabilities such as the task-manager, bug-tracker, CVS, and so on...
Anyone else interested in developing/testing should register with sourceforge and give Pavel or me an email with your SF-loginname and an indication on what you plan to do to help.

Pavel: vrecion [at] users . sourceforge . net
Stefan: stefanmelis [at] users . sourceforge . net

I also have some good news regarding the PolyLine support, see attached screenshots for details...

Cheers,
Stefan

#24: Author: pavel, Location: Czech Republic; Prague

Posted: 18/10/04 15:44
—
Well done, but if we will be so fast, what we will do tomorrow? Very Happy

Pavel

#25: Author: Stefan, Location: Belgium, Antwerp

Posted: 19/10/04 07:22
—
hahaha... whatever should we do...
euhm...? improve it! Smile

seriously, it''s not all that good yet, it's slow as hell and still will take me more of the week / month to improve it to anything stable Sad

Still you have a point.... what else is on people's wishlists?

Stefan

#26: SVG Author: pavel, Location: Czech Republic; Prague

Posted: 19/10/04 07:56
—
Hi all readers,

I have worked a little on svg glyphs.
Now I have implemented some really basic subset of svg tags.
Nevertheless I think that basic framework, that can be extended is already in place meaning that:
- svg file (which is pure xml) is opened and parsed into DOM model
- glyphs borders are calculated
- rectangles and/or lines are displayed, rest is omitted
- doubleclick displays integrated xml editor

Attached are some screen shots, including drawing glyph in svg editor (Inkscape). I hope that it gives some picture of current state.
During the work I found that:
- there is a "svg jungle", while many editors saves svg in enhanced formats (Inkscape, Sodipodi ..). Others like Corel Draw 11 seems to convert svg incorrectly (I did not studied it deeply, so I do not know if the problem was on side of Corel or SVG editor I have used)
- generaly SVG support in vector editors, inet browsers is far from ideal, but it seems to gain ground.

But I have also found that svg can be format of extended graph, while all currently implemented objects (rectangle, ellipse, polygon, link ...) can be described in svg syntax, even if we will strictly use w3c.org specs without enhancements.
This will enable to save graph and use it for example on the web without any conversion (supposing that mainstream browsers will became "svg enabled") or imported into other vector editors.

And finally ... is out of there volunteer that will help to implement other svg objects (like circles, Bezier curves) and features like gradient fill? There are interesting problems, that will train your brain.
Dear new volunteer country and humankind needs you. Very Happy

Pavel

#27: Author: pavel, Location: Czech Republic; Prague

Posted: 21/10/04 14:46
—
Hi dear reader.
we, Stefan and I, have had some direct discussion about further development that we would like to summarize as a list of questions we agreed on and which will become project tasks:

- There should be an option of user defined connection points.
- Definition of connection points is done as a part of designing shape.
- We will try to find a SVG feature for connetion points, if there is no appropriate, we will make proprietary enhancement to SVG format, similarly to sodipodi/inkscape... extensions.
- There should be some default connection points.
- Default points algorithm. During programming of optimized connector lines, we will see which approach gives the best results. So far we have in store algoritms: center based; edge division predefined and dynamic; minimal path. Center based will be easiest (as it is already implemented) edge division will by hard (?) as we will have to (dynamicilly) decide what part of the drawing is an edge (this could be troublesome when there are single lines in a drawing).
- Design of user defined connection points. Idea is based on using external shape/glyph designer, so connection points in best case scenario should be defined there.
- Current shapes (Rectangle, Circle ...) should be reimplemented so that we will have one mechanism. There is question of backward compatibility, but it is probably solveable.
- Format of shapes. Clean solution will be svg only. Vector (WMF, EMF, SVG) and bitmap formats (GIF, JPEG, BMP), are not interchangeable. To minimize this complexity it should be imported to svg using appropriate svg editor. Standardizing on SVG would be a good thing. This will even be quite helpful in determining ConnectionPoint position and such.

#28: Author: Kambiz, Location: Tehran, Iran

Posted: 21/10/04 19:17
—
Hi guys,

You are going so fast indeed, my compliments!

I'm going to update SimpleGraph's page on DELPHI AREA to inform visitors about your movement. Do you need anything particular to appear on the page?

Greetings,
Kambiz

P.S. Sorry for not being here for a couple of days.

#29: Author: pavel, Location: Czech Republic; Prague

Posted: 21/10/04 19:41
—
Thanx for appreciation, even premature one. Wink

maybe you can mention that there is possibility to join and volunteers are welcomed.
Expecially svg features can be implemented step by step and there is good opportunity to work on relatively small and separated problems like Bezier curves.

#30: Author: Stefan, Location: Belgium, Antwerp

Posted: 22/10/04 08:37
—
Thanks Kambiz Smile

I agree with Pavel. We could use help, especially with the SVG implementation. Other things aswell by the way, ideas on what to implement are more than welcome too!

#31: How to and demo Author: pavel, Location: Czech Republic; Prague

Posted: 28/10/04 21:04
—
At extgraph web pages there is brand new demo and how-to document that shows first dynamic svg graphic.
Visit

http://extgraph.sourceforge.net/docs/howto/svgclocks.htm

Kim - thanx for translation from my english to english. If you will look at new pages it will be great.
Test of how to and demo app will be appreciated, too.

Pavel

#32: Author: Kambiz, Location: Tehran, Iran

Posted: 29/10/04 08:54
—
Wonderful! Smile

#33: Author: Kambiz, Location: Tehran, Iran

Posted: 29/10/04 18:34
—
Finally, I updated TSimpleGraph's page. If you think there is something missing or the text is not clear, please let me know.

Sorry for being so late. I've got badly lazy. Sad

#34: Author: pavel, Location: Czech Republic; Prague

Posted: 29/10/04 21:00
—
Hi Kambiz.
No comments to announcement.

#35: Author: Stefan, Location: Belgium, Antwerp

Posted: 12/01/05 11:13
—
Hi all,

I've been working on bézier curve GraphLinks lately...
Some progress on the work can be seen in the screenshot below:

#36: Author: Kambiz, Location: Tehran, Iran

Posted: 12/01/05 13:18
—
WOW! Smile

#37: Author: DR Avm, Location: Russia

Posted: 24/01/05 08:32
—
Hi. All
Could you tell me where I can get last version of this component with last changes? Thanx

#38: Author: Stefan, Location: Belgium, Antwerp

Posted: 24/01/05 12:29
—
Hi,

Latest source can be downloaded from http://sourceforge.net/projects/extgraph

Pavel and I are in the process of creating a beta release with several new features. If you want the code supporting XPascal scripting, contact Pavel Vrecion (for contact info, see the extgtaph sourceforge page).

Soon we will add a new beta version supporting Bézier GraphLinks (I haven't updated this yet because I'm having trouble implementing the "label-text" by the way, any help would be appreciated Smile

)

Cheers,
Stefan

#39: Author: Vital,

Posted: 04/05/05 02:36
—
There is who alive? I want to send You its variant of the expansion SimpleGraph

#40: Author: Kambiz, Location: Tehran, Iran

Posted: 09/05/05 12:24
—
Vital,

You can attach it right here.

#41: Author: Kambiz, Location: Tehran, Iran

Posted: 13/10/05 09:09
—
It's more than one year that SimpleGraph in on SourceForge, but I don't see any new release.

Is the project stopped? Rolling Eyes

#42: Author: Stefan, Location: Belgium, Antwerp

Posted: 14/10/05 18:18
—
No - not stopped!

Actually I should be the one to take the blame for there not having been a release yet.

MeW and Pavel have done a great deal of work adding new features and stuff. Problem is that I've not really made a big enough effort to get it all together and publish a new version (albeit beta). Sorry for that.

I'll get my act together as soon as I've got my system properly set up again (too many versions of too many components and too many delphi's are making my system a processing hell!) which should be sometime soon. Sorry I can't be more specific, too damn busy with work and all.
I promiss I'll get a version published in the next month.

#43: Author: Kambiz, Location: Tehran, Iran

Posted: 15/10/05 22:34
—
That was a good news. I was afraid the project is suspended.

Cheers to all

DELPHI AREA -> DELPHI AREA's Products

output generated using printer-friendly topic mod. All times are GMT

Page 1 of 1