extgraph-developer — Extgraph developer list

[Extgraph-developer] new files in cvs

[vrecion <pav...@sy...>]

I have distributed new version to cvs repository. 

There are 

-          SVG grapher demo application with dynamic svg examples

-          Enhancements and bug fixes especially in TSVGNode implementation
ans TExtGraph Load/Save SVG file.

 

Pavel

 

[Extgraph-developer] Ping?

[Stefan M. <ste...@po...>]

Hi all,
=20
Just to say that if anybody needs a hand somewhere, I'd be happy to =
help.
=20
Stefan

RE: [Extgraph-developer] TGraphBridge (former Proxy)

[vrecion <pav...@sy...>]

Today I plan to work on it, but generally it should not affect svg node, too
much, while only different xml units will be used.

Pavel


-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Thursday, March 17, 2005 7:56 PM
To: ext...@li...
Subject: [Extgraph-developer] TGraphBridge (former Proxy)

Hi Pavel,

How are you doing in the svg refactoring stuff? I'v finally got some cvs 
access and am slowly checking in code which will nog affect other units, 
yet now I'm both fixing things and refactoring the svg-ifdefs. How are 
you progressing on getting the thing to compile? If you can send it back 
once you're basically done, I can continue repairing the baseclasses and 
you can safely continue the svg implementation (I hope).

It's  a bit of a pain to not be able to compile the stuff (or test it). 
So please let me hear from you that you are still alive and kicking.

Marco.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

Re: [Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Marco W. <in...@ca...>]

The current code (yet not released) contains implementations for Nodes 
to have a Parent. This allows similar behaviour as you describe. In 
addition I have added some methods on the Node which can disable or 
enable clicking on it's ChildNodes. Similarly moving a Node will move 
all children, Visible and Lock will also be derivable over Parent Child 
relations.

Marco.

Phil Scadden wrote:

>Okay, will do, but not immediately.
>
>Oh and yet another one. Components are heirachical. Ie a node might
>internally consist of a collection of nodes (which in turn can be made of
>smaller nodes). So aggregation and hiding are added bits. For planar
>graphs, you can manage this very easily by maintaining an incidence
>matrix. This allows you quickly calculate link to a supernode from the
>subnode links.
>
>
>----------------------------------------------------------
>Phil Scadden, Institute of Geological and Nuclear Sciences
>764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
>Ph +64 3 4799663, fax +64 3 477 5232
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>  
>

Re: [Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Marco W. <in...@ca...>]

Response below....

Phil Scadden wrote:

>>It will be interesting for us to know, which extensions you have made, not
>>only for inspiration. Maybe they can be useful also for other users. 
>>    
>>
>
>Okay. My application is drawing thermodynamic schematic of a power plant,
>which can be reduced to components linked in a planar graph (more or
>less). To this end, I have extended graphlink and nodes with the huge no.
>of properties required to characterize them. Obviously of no interest to
>anyway else. Likewise I have add many different node types to cover the
>standard symbols for pump, turbine etc. These have to be custom rather
>than graphic because there are conventions concerning where a link may
>join them. I did briefly consider generalising this. This would require a 
>node to have a property listing allowed link points. Even more complicated
>though for my application because entering link points are different from
>exiting link points.
>  
>
I've got similar requirements. However I use a information repository in 
a database. Once a node is placed onto the diagram it links up other 
nodes itself depending on the information in the database.

>Of more general use is jointed link, but I confess that I hacked this by 
>simply adding a midpoint property to link. When link is made, it calculates 
>to the midpoint, but allows the moving of this node to anywhere so link can
>do strong right-angle bends. Bezier links that I see are added address the
>same problem more generally, but again, I have convention to follow. The
>implementation changes a lot of core code
>
>Finally I added export to couple of plane-graph representations. This is so 
>I can feed a schematic into plane-graph optimiser program, get new node
>positions and then read back. This is utter hack, never intended to be more
>than a one-off exercise but is potentially a useful kind of extension.
>  
>
Using undirected graph engines is what I've been using. Similar things 
as you describe here. Perhaps we should allow an export to such a 
format. Are you using publicly available engines or some custom build ones?

Marco.

[Extgraph-developer] TGraphBridge (former Proxy)

[Marco W. <in...@ca...>]

Hi Pavel,

How are you doing in the svg refactoring stuff? I'v finally got some cvs 
access and am slowly checking in code which will nog affect other units, 
yet now I'm both fixing things and refactoring the svg-ifdefs. How are 
you progressing on getting the thing to compile? If you can send it back 
once you're basically done, I can continue repairing the baseclasses and 
you can safely continue the svg implementation (I hope).

It's  a bit of a pain to not be able to compile the stuff (or test it). 
So please let me hear from you that you are still alive and kicking.

Marco.

Re: FW: [Extgraph-developer] Status

[Marco W. <in...@ca...>]

A bit late, I'm using WinXP and D6. Depending on commercial usage D2005 may be the preferred IDE sometime soon.
Marco



Stefan Melis wrote:

>(sorry Pavel, yet again :) ) 
>
>JEDI: Test package for Delphi 3 and 4, if this doesn't work: test separate units that are used from package on Delphi 3 and 4.
>XML: No tests needed
>ExtGraph: Delphi 3-7
>
>Compiled demo-app: Win98, 2000, XP and 2003 *
>
>* if everybody's OK with this. Also, what do we do with Service Packs? Do we need to test all OS's with |and| without the SP's installed?
>
>I will mainly be using the packages on Delphi 5 with WinXP SP2. What do you guys use?
>
>Stefan
>
>-----Oorspronkelijk bericht-----
>Van: vrecion [mailto:pav...@sy...]
>Verzonden: dinsdag 8 maart 2005 17:46
>Aan: Stefan Melis
>Onderwerp: RE: [Extgraph-developer] Status
>
>>From Jedi we use only some units. 
>So for versions <5 there is option not to install package, but to add just units that are used by egGraph. There is nothing special, so I hope it will work.
>I looked into XMLPartner documentation and packages, it is for Delphi 3-7. 
>So XML compliance with 3-7 is confirmed.
>
>I am using Windows XP.
>
>Pavel
>
>-----Original Message-----
>From: Stefan Melis [mailto:ste...@po...]
>Sent: Tuesday, March 08, 2005 5:20 PM
>To: vrecion
>Subject: RE: [Extgraph-developer] Status
>
>Ah yes, I forgot about the dependencies. I guess we can safely presume that all stable releases made by these groups support what they claim to support, so we wouldn't want to double-test that. That leaves us with:
>
>JEDI-J(V)CL : Test on Delphi 3,4
>XML-Partner : Test on Delphi 3-7 *
>ExtGraph    : Test on Delphi 3-7
>
>Compiled Demo App: Test on 98, 2000, XP, 2003 **
>
>* Unless we can find proof that they already support 3-7 (or any other
>range)
>** I really need the 2000, XP and 2003 support. It's critical for me, so I'll be doing the tests anyway. 
>   I presume we're skipping ME support-tests? 
>   Win95 is getting outdated. We might indeed want to skip that and do 98 tests only?
>
>Stefan
>
>
>
>-----Oorspronkelijk bericht-----
>Van: ext...@li...
>[mailto:ext...@li...] Namens vrecion
>Verzonden: dinsdag 8 maart 2005 16:45
>Aan: ext...@li...
>Onderwerp: RE: [Extgraph-developer] Status
>
>There are some dependencies:
>- JEDI JCL/JVCL declares support for Delphi 5-2005, but I think that it should work also in 3-4 versions.
>- XML Partner declares nothing, but it should work on all Delphi versions.
>
>Testing on all Windows versions is maybe too extensive. 
>Maybe 95 or 98 and 2000 or XP should be sufficient. Demo applications can be OS sensitive, but with egGraph package the risk is low.
>What's your opinion?
>
>Pavel
>
>-----Original Message-----
>From: Stefan Melis [mailto:ste...@po...]
>Sent: Tuesday, March 08, 2005 4:21 PM
>To: vrecion
>Subject: RE: [Extgraph-developer] Status
>
>I think it's a good idea if there's one person who handles the releases on the SF pages.
>I will be very busy the next month or 2 so I won't be able to develop very much, but I would still like to contribute as much as I can, if that means doing stupid things, I'll do the stupid things ;)
>
>I think that, before we release anything, we should at least test with:
>
>Delphi 3 through 7 (I have 3, 5 and 7 already installed; and have a copy of
>4 around somewhere...)
>Windows 95, 98, 2000, XP, 2003. I've got an XP, 2000 and 2003 machine ready for testing.
>
>I wouldn't mind doing all the tests, but I'll have to do an install on an old machine for 95/98 tests.
>
>Anything else we should do?
>
>Stefan
>
>
>
>-----Oorspronkelijk bericht-----
>Van: ext...@li...
>[mailto:ext...@li...] Namens vrecion
>Verzonden: dinsdag 8 maart 2005 14:31
>Aan: ext...@li...
>Onderwerp: RE: [Extgraph-developer] Status
>
>Who will take care about release?
>If you like, I can do it, or if Stefan wants ...?.
>What we should do/test/check before release?
>
>pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of Stefan Melis
>Sent: Tuesday, March 08, 2005 12:14 PM
>To: ext...@li...
>Subject: RE: [Extgraph-developer] Status
>
>As I understand it, the CVS release is the same as the package Marco distributed to us earlier. Is that right?
>With regard to the release:
>I don't think the BezierLink is reade for release as the DrawText implementation is not correct yet. It draws the text as if it were a normal TGraphLink. I posted a question about that earlier. What should we do with that?
>
>Other than that I don't see any problems with releasing a beta with the updates that we have so far.
>
>Stefan 
>
>ps. Sorry Pavel for the double mail :)
>
>-----Oorspronkelijk bericht-----
>Van: ext...@li...
>[mailto:ext...@li...] Namens vrecion
>Verzonden: dinsdag 8 maart 2005 11:31
>Aan: ext...@li...
>Onderwerp: RE: [Extgraph-developer] Status
>
>
>Well, with the release I am not quite sure, while there is not ready important stuff - save/load of graphs.
>
>I do not quite understand TgraphProxy. Can you explain it a little?
>
>Thanx
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of Marco Wobben
>Sent: Tuesday, March 08, 2005 11:07 AM
>To: ext...@li...
>Subject: Re: [Extgraph-developer] Status
>
>Looks good to me. I've got additional work ready, do you wish to release this first as a new version and write some release info about the new stuff?
>
>Good enough to release:
>- HotTrack
>- InsertPoint, RemovePoint in the TGraphLink class
>- Fixes to BezierLink
>- TCurvedLink (Quadratic Bezier)
>
>Work in progress is:
>- TGraphProxy (for external objects identification and information. E.g.
>
>SVG or other repository formats, like I use in CaseTalk) Reference used for implementation is the design pattern book in our bookshelve. I think this will work very well and greatly extend the usability for the Graph library... ;) Ok, I'm a bit more enthousiastic because it may very well allow multiple proxies which enable it to work as a translation library as well (on the fly). More on the subject later.
>
>Regards,
>Marco.
>
>vrecion wrote:
>
>  
>
>>I have distributed packages to cvs.
>>Check it, try it, pls. Let me know.
>>Pavel
>>
>>-----Original Message-----
>>From: ext...@li...
>>[mailto:ext...@li...] On Behalf Of 
>>Marco Wobben
>>Sent: Monday, March 07, 2005 11:43 AM
>>To: ext...@li...
>>Subject: [Extgraph-developer] Status
>>
>>Hi guys,
>>
>>It's been silent for a few days and I am wondering how things are
>>    
>>
>going. 
>  
>
>>I realize the code may very well be in the hands of Stefan and I'm 
>>contuing stuff on the multipoint links. If so, please let me know what 
>>to do with some of the new methods and fixes I've made. For now I still
>>    
>>
>
>  
>
>>have a working copy and could simply send it by mail, yet I'd like to 
>>hear how things are going or where it's not going at all... ;)
>>
>>Marco.
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide Read honest & candid 
>>reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Extgraph-developer mailing list
>>Ext...@li...
>>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide Read honest & candid 
>>reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Extgraph-developer mailing list
>>Ext...@li...
>>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>>
>>
>>
>> 
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&opLk
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&opÌk
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&opÌk
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>  
>

RE: [Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Phil S. <p.s...@gn...>]

Okay, will do, but not immediately.

Oh and yet another one. Components are heirachical. Ie a node might
internally consist of a collection of nodes (which in turn can be made of
smaller nodes). So aggregation and hiding are added bits. For planar
graphs, you can manage this very easily by maintaining an incidence
matrix. This allows you quickly calculate link to a supernode from the
subnode links.


----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232

[Extgraph-developer] One more change...

[Phil S. <p.s...@gn...>]

Another one that is quite important.

Simplegraph "out of the box" doesn't allow multiple links connecting
the same nodes, but real world has such thing for either redundancy
or efficiency. Allowing them is easy but then have make sure that links
are parallel lines not just on top of each other. A cleaner implementation 
of this is possible, I am sure.

----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232

[Extgraph-developer] Changes I've made (Was Improved drawing zoomed canvas)

[Phil S. <p.s...@gn...>]

> It will be interesting for us to know, which extensions you have made, not
> only for inspiration. Maybe they can be useful also for other users. 

Okay. My application is drawing thermodynamic schematic of a power plant,
which can be reduced to components linked in a planar graph (more or
less). To this end, I have extended graphlink and nodes with the huge no.
of properties required to characterize them. Obviously of no interest to
anyway else. Likewise I have add many different node types to cover the
standard symbols for pump, turbine etc. These have to be custom rather
than graphic because there are conventions concerning where a link may
join them. I did briefly consider generalising this. This would require a 
node to have a property listing allowed link points. Even more complicated
though for my application because entering link points are different from
exiting link points.

Of more general use is jointed link, but I confess that I hacked this by 
simply adding a midpoint property to link. When link is made, it calculates 
to the midpoint, but allows the moving of this node to anywhere so link can
do strong right-angle bends. Bezier links that I see are added address the
same problem more generally, but again, I have convention to follow. The
implementation changes a lot of core code

Finally I added export to couple of plane-graph representations. This is so 
I can feed a schematic into plane-graph optimiser program, get new node
positions and then read back. This is utter hack, never intended to be more
than a one-off exercise but is potentially a useful kind of extension.

----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232

RE: [Extgraph-developer] Architecture talk (aka Proxy)

[Pavel V. <cz3...@ti...>]

OK Marco send me a code or make changes in cvs.
My plans are:
- to create something like xml proxy object. Reason is loosen dependency
on XML Partner implementation and to get rid of changed XPDom.
- I have created a mess in cvs repository - mainly due to my not so steep=

learning curve :-) .
- New demo application to test and show svg stuff.

Pavel 

>-- P=F9vodn=ED zpr=E1va --
>From: Marco Wobben <in...@ca...>
>To: ext...@li...
>Subject: [Extgraph-developer] Architecture talk (aka Proxy)
>Date: Tue, 15 Mar 2005 13:08:01 +0100
>
>
>Ok guys,
>
>I've had a change of mind. The previously mentioned Proxy component is

>not really a proxy but more of a Bridge. Thinking this through more and

>more doesn't reduce the work at hand. I've more or less re-factored the

>svg into a egSvgBridge, egSvgNodes and implemented a very(!) rough 
>TExtGraphBridge. At this moment it is nothing more than extracting the

>svg stuff and pushing it into a seperate unit. The two-way communication=

>
>between the xml dom tree and the ExtGraph is not complete. Since I don't=

>
>have the xml components I won't get it to work as easily as I would like=

>to.
>
>So, to divide the workload I would like Parvel to have a look and see if=

>
>he can repair the damage I've done to it. My future thoughts on the 
>Bridge technology goes beyond the svg implementation. It would even 
>allow multiple ExtGraphs with a single Bridge. To really make this work,=

>
>more internals on node and link manipulation need to be extracted from

>the ExtGraph class. More logic needs to go into the ExtGraphBridge 
>class. Not really difficult, yet it requires a lot of work and re-factor=
ing.
>
>I'm thinking to far beyond to pull this off in a single increment. The

>idea is to go towards the following architecture in several code increme=
nts:
>
>ExtGraph -> CustomBridge
>                 |
>           /-----------\
>      ExtBridge     SvgBridge
>
>
>              GraphObject
>                   |
>                   ^
>              /---------\
>          GraphNode  GraphLink
>             |               \
>             ^                \
>        /---------\            \--------\
>RectangleNode  SvgNode          \        \
>                           BezierLink CurvedLink
>
>
>ExtGraph is to be responsible for the drawing and gui of the graph 
>itself. It will still control all nodes and links, yet allows the 
>ExtBridge to intercept all communication on the collection of nodes and

>links it displays. Instead of having eventhandlers on the ExtGraph 
>itself these will be moved towards (or extended on) the ExtBridge. The

>other way around the Bridge will contain methods to insert nodes and 
>links into the ExtGraph. Different bridge classes, like SvgBridge, will

>service other methods which allow a different language (svg) to be used

>to manipulate the nodes and links on the ExtGraph.
>
>I do hope this makes sence to you all. I can barely keep up my thought

>train, and certainly miss the time to implement all of this. Yet my gut

>feeling says this is the way to proceed as far as the architecture is 
>involved. If you have the energy and insight please come back to me on

>this or help me convert at least a SvgBridge to make this first 
>increment work. Personally I will attempt to continue the work on a 
>ExtBridge layer and a custom Bridge for CaseTalk and see what is needed

>for the communication between components to make it all work transparent=
...
>
>Hope you are all well and coding. ;)
>
>Regards,
>Marco.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.=

>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer


-------------------------- 
Pos=EDlejte SMS p=F8es internet zdarma a bez reklamy. Pouze s TISCALI. 
V=EDce na http://www.tiscali.cz 

[Extgraph-developer] Architecture talk (aka Proxy)

[Marco W. <in...@ca...>]

Ok guys,

I've had a change of mind. The previously mentioned Proxy component is 
not really a proxy but more of a Bridge. Thinking this through more and 
more doesn't reduce the work at hand. I've more or less re-factored the 
svg into a egSvgBridge, egSvgNodes and implemented a very(!) rough 
TExtGraphBridge. At this moment it is nothing more than extracting the 
svg stuff and pushing it into a seperate unit. The two-way communication 
between the xml dom tree and the ExtGraph is not complete. Since I don't 
have the xml components I won't get it to work as easily as I would like to.

So, to divide the workload I would like Parvel to have a look and see if 
he can repair the damage I've done to it. My future thoughts on the 
Bridge technology goes beyond the svg implementation. It would even 
allow multiple ExtGraphs with a single Bridge. To really make this work, 
more internals on node and link manipulation need to be extracted from 
the ExtGraph class. More logic needs to go into the ExtGraphBridge 
class. Not really difficult, yet it requires a lot of work and re-factoring.

I'm thinking to far beyond to pull this off in a single increment. The 
idea is to go towards the following architecture in several code increments:

ExtGraph -> CustomBridge
                 |
           /-----------\
      ExtBridge     SvgBridge


              GraphObject
                   |
                   ^
              /---------\
          GraphNode  GraphLink
             |               \
             ^                \
        /---------\            \--------\
RectangleNode  SvgNode          \        \
                           BezierLink CurvedLink


ExtGraph is to be responsible for the drawing and gui of the graph 
itself. It will still control all nodes and links, yet allows the 
ExtBridge to intercept all communication on the collection of nodes and 
links it displays. Instead of having eventhandlers on the ExtGraph 
itself these will be moved towards (or extended on) the ExtBridge. The 
other way around the Bridge will contain methods to insert nodes and 
links into the ExtGraph. Different bridge classes, like SvgBridge, will 
service other methods which allow a different language (svg) to be used 
to manipulate the nodes and links on the ExtGraph.

I do hope this makes sence to you all. I can barely keep up my thought 
train, and certainly miss the time to implement all of this. Yet my gut 
feeling says this is the way to proceed as far as the architecture is 
involved. If you have the energy and insight please come back to me on 
this or help me convert at least a SvgBridge to make this first 
increment work. Personally I will attempt to continue the work on a 
ExtBridge layer and a custom Bridge for CaseTalk and see what is needed 
for the communication between components to make it all work transparent...

Hope you are all well and coding. ;)

Regards,
Marco.

RE: [Extgraph-developer] Improved drawing of zoomed canvas etc.

[vrecion <pav...@sy...>]

Dear Phill,
Thanks for your remarks and recommendations. We will try to implement it
future versions.

It will be interesting for us to know, which extensions you have made, not
only for inspiration. Maybe they can be useful also for other users. 

Pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of Phil
Scadden
Sent: Tuesday, March 15, 2005 2:38 AM
To: ext...@li...
Subject: [Extgraph-developer] Improved drawing of zoomed canvas etc.

Hi. I have joined Extgraph list as busy hacking SimpleGraph for my own
application. Added jointed links and also a host of new node types for
my application.

However, I have got to an issue that might be of general interest. 
Simplegraph has relatively involved painting method. It paints to a bitmap
which is then bitlblt to the canvas. This has a few downsides, particularly
in that as you zoom in, instead of seeing more text, text is simply 
enlarged, lines are thickened etc. I want to zoom so that can see more text 
and keep lines at same weight.  I also looked at less involved way of 
painting but see that it is done because zoom method includes arbitary
rounding. This can be avoided but developer perhaps didn't spot it. I tried
with setworldTransform or setviewport setwindowextext calls but hit the
rounding issue as the code is structured at the moment.

Proper scaling on zoom requires transforming the graph coords by
x' = x*scale + scaledoffset. To avoid problem with rounding, think the
actual calculation is
x' = muldiv(x,M,D) + offset, where M is max(clientHeight, clientwidth) and
D is M*100/Zoom percent

The easier way to introduce this scaling would be a derivative of
TCanvas say TScaleableCanvas with overriddern draw methods to scale
the x,y coordinates before calling inherited draw methods.

Sadly this approach is no go. MoveTo, LineTo etc etc are static methods
in TCanvas. You can replace with static MoveTo, LineTo, but then the
drawing calls have to reference TScaleCanvas to the replaced method.
Once you do this, you cant pass TMetafileCanvas or Printer.Canvas to
the draw methods. 

Unless someone has a better idea, I think the only way to achieve what I
want is explicit scaling of coordinates in the drawing calls. This would a
big impact on ExtGraph, perhaps rather more than you would want.


----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

[Extgraph-developer] Improved drawing of zoomed canvas etc.

[Phil S. <p.s...@gn...>]

Hi. I have joined Extgraph list as busy hacking SimpleGraph for my own
application. Added jointed links and also a host of new node types for
my application.

However, I have got to an issue that might be of general interest. 
Simplegraph has relatively involved painting method. It paints to a bitmap
which is then bitlblt to the canvas. This has a few downsides, particularly
in that as you zoom in, instead of seeing more text, text is simply 
enlarged, lines are thickened etc. I want to zoom so that can see more text 
and keep lines at same weight.  I also looked at less involved way of 
painting but see that it is done because zoom method includes arbitary
rounding. This can be avoided but developer perhaps didn't spot it. I tried
with setworldTransform or setviewport setwindowextext calls but hit the
rounding issue as the code is structured at the moment.

Proper scaling on zoom requires transforming the graph coords by
x' = x*scale + scaledoffset. To avoid problem with rounding, think the
actual calculation is
x' = muldiv(x,M,D) + offset, where M is max(clientHeight, clientwidth) and
D is M*100/Zoom percent

The easier way to introduce this scaling would be a derivative of
TCanvas say TScaleableCanvas with overriddern draw methods to scale
the x,y coordinates before calling inherited draw methods.

Sadly this approach is no go. MoveTo, LineTo etc etc are static methods
in TCanvas. You can replace with static MoveTo, LineTo, but then the
drawing calls have to reference TScaleCanvas to the replaced method.
Once you do this, you cant pass TMetafileCanvas or Printer.Canvas to
the draw methods. 

Unless someone has a better idea, I think the only way to achieve what I
want is explicit scaling of coordinates in the drawing calls. This would a
big impact on ExtGraph, perhaps rather more than you would want.


----------------------------------------------------------
Phil Scadden, Institute of Geological and Nuclear Sciences
764 Cumberland St, Private Bag 1930, Dunedin, New Zealand
Ph +64 3 4799663, fax +64 3 477 5232

Re: [Extgraph-developer] The TGraphProxy Idea

[Marco W. <in...@ca...>]

Thanks, I will certainly continue the writing and coding. And I realize 
the common goals need time and much discussion. I already have such 
discussion with my collegues and email tends to be a bit more 
distracting and slower. We will continue emailing. ;) Have fun in the 
mountains.

Marco.

vrecion wrote:

>P.S. 
>I would like to add just one comment.
>As we already discussed with Stefan earlier, we consider the state when
>extGraph development is "application driven" as healthy one and warmly
>welcomed.
>
>So, Marco, do not be afraid about support, your application needs has
>priority and should be taken into account.
>It is often difficult and time consuming to get to common understanding, but
>I am quite optimistic that we will find solutions together. 
>IMHO, Marco, you are already benefitial to the project and your contribution
>is already significant.
>
>Pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of Marco
>Wobben
>Sent: Tuesday, March 08, 2005 2:22 PM
>To: ext...@li...
>Subject: [Extgraph-developer] The TGraphProxy Idea
>
>Hi guys,
>
>I've joined the SimpleGraph developers group to be able to implement
>features in the Graph library for a specific graph library purpose. I
>need it to display information from a repository and not have it any
>other way. The link between stored information and the visual
>representation requires identification and information to be portable to
>and from the graphs. For this sollution I think a TGraphProxy is
>required. Reading up on several design patterns, I've came to the
>conclusion that this pattern is the way to go for this issue.
>
>This would solve another issue I commented on earlier, SVG
>implementation within the main source and baseclasses. I'm still working
>on a first draft and hope to get it working sometime soon. Implementing
>such a sollution has a personal high priority. Extracting technically
>specific code implementation (like SVG, but also in my case other
>standards) would bring back the focus where it should be. Focus on SVG
>in the SVG code and focus for TExtGraph in the graph code. (And needless
>to say I can focus on other standards without complaining or having to
>worry too much about IFDEFs and other code implementations I do not
>require.)
>
>So what about this so called TGraphProxy? The answer I'm given is
>partially based upon my finding in the current SVG code and partially on
>my 'not implemented yet' needs. What I can see in the Graph classes are
>the following items:
>
>- GraphObjects are identified.
>- GraphObjects have properties.
>- GraphObjects are added, removed and updated.
>
>The internals of TGraph(Objects) perform all these actions, and specific
>descendant classes add functionality for a specific display feature. My
>idea is to have the above list of functionality published to an external
>component, a Proxy. A TExtGraph would have a publised property which is
>to be a component link to a TCustomGraphProxy. Whenever a object is
>inserted (removed or updated) it should trigger a method on the Proxy.
>Off course the proxy would do this both ways so that a technical
>implementation (e.g. SVG) would add an element it would at this as a
>proper TGraphObject to the appropriate TExtGraph instance.
>
>Synchronization options can be set at the Proxy. In case of SVG, one
>would probably want the XmlDom to be a reflection off the Graph, meaning
>that it must be fully synchronized. Other sollutions may be implemented,
>having a one way sync for instance would allow a repository of objects
>being available to be drawn.
>
>Here my description stops, since I need to implement this in a
>prototype, but I'm convinced this could very well work and allow other
>developers to add new technical layers very easily. Additionally,
>perhaps needless to say, multiple proxies could allow object translation
>on the fly. Having both Graph, SVG and other standards simultaniously...
>
>So far my deep thoughs and ambition.
>
>Marco.
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>  
>

RE: [Extgraph-developer] Related projects

[vrecion <pav...@sy...>]

I think that it can be good advertisement for companies and their =
projects
as well as for extGraph.
pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Stefan
Melis
Sent: Wednesday, March 09, 2005 12:02 PM
To: ext...@li...
Subject: [Extgraph-developer] Related projects

Hi guys,

Marco, I was just wondering if we could add the CaseTalk website to the
related projects page on
http://extgraph.sourceforge.net/relatedprojects.htm ?
I think that would be a nice addition.=20
We (Pfister-Bilanciai) will probably be setting up a website for our
product (WinWeigh / CLEARWeigh) the comming months and we could add it
to the related projects site aswell, along with a testimonial or
something.

What do you think?

Stefan


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&opLk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

[Extgraph-developer] Related projects

[Stefan M. <ste...@po...>]

Hi guys,

Marco, I was just wondering if we could add the CaseTalk website to the
related projects page on
http://extgraph.sourceforge.net/relatedprojects.htm ?
I think that would be a nice addition.=20
We (Pfister-Bilanciai) will probably be setting up a website for our
product (WinWeigh / CLEARWeigh) the comming months and we could add it
to the related projects site aswell, along with a testimonial or
something.

What do you think?

Stefan

RE: [Extgraph-developer] Status

[vrecion <pav...@sy...>]

I use mainly Delphi 7 on XP/SP2.
I am trying Delphi 2005, but I am not sure with it, yet.
pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Stefan
Melis
Sent: Tuesday, March 08, 2005 6:21 PM
To: ext...@li...
Subject: FW: [Extgraph-developer] Status

(sorry Pavel, yet again :) )=20

JEDI: Test package for Delphi 3 and 4, if this doesn't work: test =
separate
units that are used from package on Delphi 3 and 4.
XML: No tests needed
ExtGraph: Delphi 3-7

Compiled demo-app: Win98, 2000, XP and 2003 *

* if everybody's OK with this. Also, what do we do with Service Packs? =
Do we
need to test all OS's with |and| without the SP's installed?

I will mainly be using the packages on Delphi 5 with WinXP SP2. What do =
you
guys use?

Stefan

-----Oorspronkelijk bericht-----
Van: vrecion [mailto:pav...@sy...]
Verzonden: dinsdag 8 maart 2005 17:46
Aan: Stefan Melis
Onderwerp: RE: [Extgraph-developer] Status

>From Jedi we use only some units.=20
So for versions <5 there is option not to install package, but to add =
just
units that are used by egGraph. There is nothing special, so I hope it =
will
work.
I looked into XMLPartner documentation and packages, it is for Delphi =
3-7.=20
So XML compliance with 3-7 is confirmed.

I am using Windows XP.

Pavel

-----Original Message-----
From: Stefan Melis [mailto:ste...@po...]
Sent: Tuesday, March 08, 2005 5:20 PM
To: vrecion
Subject: RE: [Extgraph-developer] Status

Ah yes, I forgot about the dependencies. I guess we can safely presume =
that
all stable releases made by these groups support what they claim to =
support,
so we wouldn't want to double-test that. That leaves us with:

JEDI-J(V)CL : Test on Delphi 3,4
XML-Partner : Test on Delphi 3-7 *
ExtGraph    : Test on Delphi 3-7

Compiled Demo App: Test on 98, 2000, XP, 2003 **

* Unless we can find proof that they already support 3-7 (or any other
range)
** I really need the 2000, XP and 2003 support. It's critical for me, so
I'll be doing the tests anyway.=20
   I presume we're skipping ME support-tests?=20
   Win95 is getting outdated. We might indeed want to skip that and do =
98
tests only?

Stefan



-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 16:45
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status

There are some dependencies:
- JEDI JCL/JVCL declares support for Delphi 5-2005, but I think that it
should work also in 3-4 versions.
- XML Partner declares nothing, but it should work on all Delphi =
versions.

Testing on all Windows versions is maybe too extensive.=20
Maybe 95 or 98 and 2000 or XP should be sufficient. Demo applications =
can be
OS sensitive, but with egGraph package the risk is low.
What's your opinion?

Pavel

-----Original Message-----
From: Stefan Melis [mailto:ste...@po...]
Sent: Tuesday, March 08, 2005 4:21 PM
To: vrecion
Subject: RE: [Extgraph-developer] Status

I think it's a good idea if there's one person who handles the releases =
on
the SF pages.
I will be very busy the next month or 2 so I won't be able to develop =
very
much, but I would still like to contribute as much as I can, if that =
means
doing stupid things, I'll do the stupid things ;)

I think that, before we release anything, we should at least test with:

Delphi 3 through 7 (I have 3, 5 and 7 already installed; and have a copy =
of
4 around somewhere...)
Windows 95, 98, 2000, XP, 2003. I've got an XP, 2000 and 2003 machine =
ready
for testing.

I wouldn't mind doing all the tests, but I'll have to do an install on =
an
old machine for 95/98 tests.

Anything else we should do?

Stefan



-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 14:31
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status

Who will take care about release?
If you like, I can do it, or if Stefan wants ...?.
What we should do/test/check before release?

pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Stefan
Melis
Sent: Tuesday, March 08, 2005 12:14 PM
To: ext...@li...
Subject: RE: [Extgraph-developer] Status

As I understand it, the CVS release is the same as the package Marco
distributed to us earlier. Is that right?
With regard to the release:
I don't think the BezierLink is reade for release as the DrawText
implementation is not correct yet. It draws the text as if it were a =
normal
TGraphLink. I posted a question about that earlier. What should we do =
with
that?

Other than that I don't see any problems with releasing a beta with the
updates that we have so far.

Stefan=20

ps. Sorry Pavel for the double mail :)

-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 11:31
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status


Well, with the release I am not quite sure, while there is not ready
important stuff - save/load of graphs.

I do not quite understand TgraphProxy. Can you explain it a little?

Thanx

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Marco
Wobben
Sent: Tuesday, March 08, 2005 11:07 AM
To: ext...@li...
Subject: Re: [Extgraph-developer] Status

Looks good to me. I've got additional work ready, do you wish to release
this first as a new version and write some release info about the new =
stuff?

Good enough to release:
- HotTrack
- InsertPoint, RemovePoint in the TGraphLink class
- Fixes to BezierLink
- TCurvedLink (Quadratic Bezier)

Work in progress is:
- TGraphProxy (for external objects identification and information. E.g.

SVG or other repository formats, like I use in CaseTalk) Reference used =
for
implementation is the design pattern book in our bookshelve. I think =
this
will work very well and greatly extend the usability for the Graph
library... ;) Ok, I'm a bit more enthousiastic because it may very well
allow multiple proxies which enable it to work as a translation library =
as
well (on the fly). More on the subject later.

Regards,
Marco.

vrecion wrote:

>I have distributed packages to cvs.
>Check it, try it, pls. Let me know.
>Pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of=20
>Marco Wobben
>Sent: Monday, March 07, 2005 11:43 AM
>To: ext...@li...
>Subject: [Extgraph-developer] Status
>
>Hi guys,
>
>It's been silent for a few days and I am wondering how things are
going.=20
>I realize the code may very well be in the hands of Stefan and I'm=20
>contuing stuff on the multipoint links. If so, please let me know what=20
>to do with some of the new methods and fixes I've made. For now I still

>have a working copy and could simply send it by mail, yet I'd like to=20
>hear how things are going or where it's not going at all... ;)
>
>Marco.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid=20
>reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid=20
>reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
> =20
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&opLk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer









-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

FW: [Extgraph-developer] Status

[Stefan M. <ste...@po...>]

(sorry Pavel, yet again :) )=20

JEDI: Test package for Delphi 3 and 4, if this doesn't work: test =
separate units that are used from package on Delphi 3 and 4.
XML: No tests needed
ExtGraph: Delphi 3-7

Compiled demo-app: Win98, 2000, XP and 2003 *

* if everybody's OK with this. Also, what do we do with Service Packs? =
Do we need to test all OS's with |and| without the SP's installed?

I will mainly be using the packages on Delphi 5 with WinXP SP2. What do =
you guys use?

Stefan

-----Oorspronkelijk bericht-----
Van: vrecion [mailto:pav...@sy...]
Verzonden: dinsdag 8 maart 2005 17:46
Aan: Stefan Melis
Onderwerp: RE: [Extgraph-developer] Status

From Jedi we use only some units.=20
So for versions <5 there is option not to install package, but to add =
just units that are used by egGraph. There is nothing special, so I hope =
it will work.
I looked into XMLPartner documentation and packages, it is for Delphi =
3-7.=20
So XML compliance with 3-7 is confirmed.

I am using Windows XP.

Pavel

-----Original Message-----
From: Stefan Melis [mailto:ste...@po...]
Sent: Tuesday, March 08, 2005 5:20 PM
To: vrecion
Subject: RE: [Extgraph-developer] Status

Ah yes, I forgot about the dependencies. I guess we can safely presume =
that all stable releases made by these groups support what they claim to =
support, so we wouldn't want to double-test that. That leaves us with:

JEDI-J(V)CL : Test on Delphi 3,4
XML-Partner : Test on Delphi 3-7 *
ExtGraph    : Test on Delphi 3-7

Compiled Demo App: Test on 98, 2000, XP, 2003 **

* Unless we can find proof that they already support 3-7 (or any other
range)
** I really need the 2000, XP and 2003 support. It's critical for me, so =
I'll be doing the tests anyway.=20
   I presume we're skipping ME support-tests?=20
   Win95 is getting outdated. We might indeed want to skip that and do =
98 tests only?

Stefan



-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 16:45
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status

There are some dependencies:
- JEDI JCL/JVCL declares support for Delphi 5-2005, but I think that it =
should work also in 3-4 versions.
- XML Partner declares nothing, but it should work on all Delphi =
versions.

Testing on all Windows versions is maybe too extensive.=20
Maybe 95 or 98 and 2000 or XP should be sufficient. Demo applications =
can be OS sensitive, but with egGraph package the risk is low.
What's your opinion?

Pavel

-----Original Message-----
From: Stefan Melis [mailto:ste...@po...]
Sent: Tuesday, March 08, 2005 4:21 PM
To: vrecion
Subject: RE: [Extgraph-developer] Status

I think it's a good idea if there's one person who handles the releases =
on the SF pages.
I will be very busy the next month or 2 so I won't be able to develop =
very much, but I would still like to contribute as much as I can, if =
that means doing stupid things, I'll do the stupid things ;)

I think that, before we release anything, we should at least test with:

Delphi 3 through 7 (I have 3, 5 and 7 already installed; and have a copy =
of
4 around somewhere...)
Windows 95, 98, 2000, XP, 2003. I've got an XP, 2000 and 2003 machine =
ready for testing.

I wouldn't mind doing all the tests, but I'll have to do an install on =
an old machine for 95/98 tests.

Anything else we should do?

Stefan



-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 14:31
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status

Who will take care about release?
If you like, I can do it, or if Stefan wants ...?.
What we should do/test/check before release?

pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Stefan Melis
Sent: Tuesday, March 08, 2005 12:14 PM
To: ext...@li...
Subject: RE: [Extgraph-developer] Status

As I understand it, the CVS release is the same as the package Marco =
distributed to us earlier. Is that right?
With regard to the release:
I don't think the BezierLink is reade for release as the DrawText =
implementation is not correct yet. It draws the text as if it were a =
normal TGraphLink. I posted a question about that earlier. What should =
we do with that?

Other than that I don't see any problems with releasing a beta with the =
updates that we have so far.

Stefan=20

ps. Sorry Pavel for the double mail :)

-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 11:31
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status


Well, with the release I am not quite sure, while there is not ready =
important stuff - save/load of graphs.

I do not quite understand TgraphProxy. Can you explain it a little?

Thanx

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Marco Wobben
Sent: Tuesday, March 08, 2005 11:07 AM
To: ext...@li...
Subject: Re: [Extgraph-developer] Status

Looks good to me. I've got additional work ready, do you wish to release =
this first as a new version and write some release info about the new =
stuff?

Good enough to release:
- HotTrack
- InsertPoint, RemovePoint in the TGraphLink class
- Fixes to BezierLink
- TCurvedLink (Quadratic Bezier)

Work in progress is:
- TGraphProxy (for external objects identification and information. E.g.

SVG or other repository formats, like I use in CaseTalk) Reference used =
for implementation is the design pattern book in our bookshelve. I think =
this will work very well and greatly extend the usability for the Graph =
library... ;) Ok, I'm a bit more enthousiastic because it may very well =
allow multiple proxies which enable it to work as a translation library =
as well (on the fly). More on the subject later.

Regards,
Marco.

vrecion wrote:

>I have distributed packages to cvs.
>Check it, try it, pls. Let me know.
>Pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of=20
>Marco Wobben
>Sent: Monday, March 07, 2005 11:43 AM
>To: ext...@li...
>Subject: [Extgraph-developer] Status
>
>Hi guys,
>
>It's been silent for a few days and I am wondering how things are
going.=20
>I realize the code may very well be in the hands of Stefan and I'm=20
>contuing stuff on the multipoint links. If so, please let me know what=20
>to do with some of the new methods and fixes I've made. For now I still

>have a working copy and could simply send it by mail, yet I'd like to=20
>hear how things are going or where it's not going at all... ;)
>
>Marco.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid=20
>reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid=20
>reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
> =20
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&opLk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer






-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

RE: [Extgraph-developer] The TGraphProxy Idea

[vrecion <pav...@sy...>]

OK.
I am interested. BTW Thursday I am going to mountains, to break a skis or
leg. :-)
So I will be on-line till tomorrow morning and then Monday.

Pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Tuesday, March 08, 2005 4:47 PM
To: ext...@li...
Subject: Re: [Extgraph-developer] The TGraphProxy Idea

I haven't got much time right now and want to come back on this. In the 
meanwhile let me just finish my proto and send you an email later this 
week (hopefully). I think just by refactoring some code I can show you 
what I have in mind. I do realize that you are abstracting the drawing 
stuff to the svg elements. However this doesn't abstract the data 
definition layer yet. If you continue this way, the SimpleGraph will do 
nothing but offer a bitmap for the svg-elements and you will end up with 
a new layer being implemented behind svg, since any data repository now 
has to create the svg elements and the drawing specifics...

The proxy will solve both since you'll be able to have multiple data 
storage fascilities which all take part in the grand-proces of drawing 
stuff...

Please let me show you later on...

Marco.

vrecion wrote:

>Lively discussion, isn't it? :-)
>That is what I like a lot in OS projects, really.
>I am afraid (but not sure) that there is misunderstanding of SVG idea.
>So excuse me if I will explain something that you are aware of already.
>There are two parts of SVG:
>- first is way, how data are stored in streams or files. Here SVG can be
one
>of the more formats.
>- second is the way of in memory objects representation
>
>I will discuss only the second part.
>We have several graph objects that has different graphical representations.
>They are nodes of same class:
>- TpolygonalNode
>- TrectangularNode
>- TroundRectangularNode
>- TroundRectangularNode
>- TellipticNode
>- TtriangularNode
>- TrhomboidalNode
>- TpentagonalNode
>
>There are also links, connecting nodes, but I will leave them aside for a
>while.
>
>Idea is to remove all nodes and replace them with SVG node that will have
>xml element where graphical shape is stored.
>Where are advantages of such approach?
>Imagine that you would need to add other shape for example cylinder for
>graphical representation of database. You will have to create another
object
>called say TcylinderNode and to implement it.
>In the case of SVG you will just supply different xml during node creation,
>without touching core classes.
>With svg node other shapes (like box with circles for firewall) are really
>easy to achieve.
>Some examples:
>Rectangular node is svg node with following xml:
><g id="1">
> <rect x="1" y="1" width="1198" height="398"/>
> <text x="20" y="20">This is rectangle</text>
></g>
>In fact svg graph object works with dom, so node shape can be created
>programatically either by parsing text or creating xml nodes like:
>SomeObject.SVG.AddChild(SVG.Document.createElement('rect').setAttribute('x'
,
>'1')); ...
>
>Another example:
><g id="2" width="300" height="300">
> <circle cx="150" cy="50" r="40" stroke="black" stroke-width="2"
>fill="bisque"/>
> <line x1="150" y1="90" x2="150" y2="200" stroke-width="2"/>
> <line x1="150" y1="200" x2="100" y2="300" stroke-width="2"/>
> <line x1="150" y1="200" x2="200" y2="300" stroke-width="2"/>
> <line x1="150" y1="120" x2="100" y2="200" stroke-width="2"/>
> <line x1="150" y1="120" x2="200" y2="200" stroke-width="2"/>
></svg>
>This xml processed by SVG node draws figure used as an Actor in UML
>diagrams.
>
>Equally straightforward is creation of specialized nodes. For example nodes
>storing data and processing them. Say that you need special node that will
>store and display integer value.
>You will the write something like this:
>
>TmyNode = class(TSVGNode)
>Private
> Function getMyInt:Integer;
> Procedure setMyInt(i:Integer);
>Property
> MyInt:Integer read getMyInt write setMyInt; 
>End;
>
>....
>Function TmyNode.getMyInt:Integer;
>Begin
> If SVG.FirstTag('data')<>nil
>  Then Result:=SVG.FirstTag('data').AsInteger //suppose that you decided to
>store your data in element with data tag
>  Else Result:=-1; // default value
>End;
>
>Procedure TmyNode.setMyInt(i:Integer);
>Begin
>If SVG.FirstTag('data')<>nil
>  Then SVG.FirstTag('data').AsInteger:=i 
>  Else SVG.AddChildElement('data').AsInteger:=i;  // create element and
fill
>value
>End;
>
>
>That is why there is svg code in current nodes, i.e. because of backward
>compatibility. But I agree that it makes code complex (I promise - will try
>to find another way to get both clener code and backward compatibility)
>
>Pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of Marco
>Wobben
>Sent: Tuesday, March 08, 2005 2:22 PM
>To: ext...@li...
>Subject: [Extgraph-developer] The TGraphProxy Idea
>
>Hi guys,
>
>I've joined the SimpleGraph developers group to be able to implement
>features in the Graph library for a specific graph library purpose. I
>need it to display information from a repository and not have it any
>other way. The link between stored information and the visual
>representation requires identification and information to be portable to
>and from the graphs. For this sollution I think a TGraphProxy is
>required. Reading up on several design patterns, I've came to the
>conclusion that this pattern is the way to go for this issue.
>
>This would solve another issue I commented on earlier, SVG
>implementation within the main source and baseclasses. I'm still working
>on a first draft and hope to get it working sometime soon. Implementing
>such a sollution has a personal high priority. Extracting technically
>specific code implementation (like SVG, but also in my case other
>standards) would bring back the focus where it should be. Focus on SVG
>in the SVG code and focus for TExtGraph in the graph code. (And needless
>to say I can focus on other standards without complaining or having to
>worry too much about IFDEFs and other code implementations I do not
>require.)
>
>So what about this so called TGraphProxy? The answer I'm given is
>partially based upon my finding in the current SVG code and partially on
>my 'not implemented yet' needs. What I can see in the Graph classes are
>the following items:
>
>- GraphObjects are identified.
>- GraphObjects have properties.
>- GraphObjects are added, removed and updated.
>
>The internals of TGraph(Objects) perform all these actions, and specific
>descendant classes add functionality for a specific display feature. My
>idea is to have the above list of functionality published to an external
>component, a Proxy. A TExtGraph would have a publised property which is
>to be a component link to a TCustomGraphProxy. Whenever a object is
>inserted (removed or updated) it should trigger a method on the Proxy.
>Off course the proxy would do this both ways so that a technical
>implementation (e.g. SVG) would add an element it would at this as a
>proper TGraphObject to the appropriate TExtGraph instance.
>
>Synchronization options can be set at the Proxy. In case of SVG, one
>would probably want the XmlDom to be a reflection off the Graph, meaning
>that it must be fully synchronized. Other sollutions may be implemented,
>having a one way sync for instance would allow a repository of objects
>being available to be drawn.
>
>Here my description stops, since I need to implement this in a
>prototype, but I'm convinced this could very well work and allow other
>developers to add new technical layers very easily. Additionally,
>perhaps needless to say, multiple proxies could allow object translation
>on the fly. Having both Graph, SVG and other standards simultaniously...
>
>So far my deep thoughs and ambition.
>
>Marco.
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>  
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

RE: [Extgraph-developer] The TGraphProxy Idea

[vrecion <pav...@sy...>]

P.S. 
I would like to add just one comment.
As we already discussed with Stefan earlier, we consider the state when
extGraph development is "application driven" as healthy one and warmly
welcomed.

So, Marco, do not be afraid about support, your application needs has
priority and should be taken into account.
It is often difficult and time consuming to get to common understanding, but
I am quite optimistic that we will find solutions together. 
IMHO, Marco, you are already benefitial to the project and your contribution
is already significant.

Pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Tuesday, March 08, 2005 2:22 PM
To: ext...@li...
Subject: [Extgraph-developer] The TGraphProxy Idea

Hi guys,

I've joined the SimpleGraph developers group to be able to implement
features in the Graph library for a specific graph library purpose. I
need it to display information from a repository and not have it any
other way. The link between stored information and the visual
representation requires identification and information to be portable to
and from the graphs. For this sollution I think a TGraphProxy is
required. Reading up on several design patterns, I've came to the
conclusion that this pattern is the way to go for this issue.

This would solve another issue I commented on earlier, SVG
implementation within the main source and baseclasses. I'm still working
on a first draft and hope to get it working sometime soon. Implementing
such a sollution has a personal high priority. Extracting technically
specific code implementation (like SVG, but also in my case other
standards) would bring back the focus where it should be. Focus on SVG
in the SVG code and focus for TExtGraph in the graph code. (And needless
to say I can focus on other standards without complaining or having to
worry too much about IFDEFs and other code implementations I do not
require.)

So what about this so called TGraphProxy? The answer I'm given is
partially based upon my finding in the current SVG code and partially on
my 'not implemented yet' needs. What I can see in the Graph classes are
the following items:

- GraphObjects are identified.
- GraphObjects have properties.
- GraphObjects are added, removed and updated.

The internals of TGraph(Objects) perform all these actions, and specific
descendant classes add functionality for a specific display feature. My
idea is to have the above list of functionality published to an external
component, a Proxy. A TExtGraph would have a publised property which is
to be a component link to a TCustomGraphProxy. Whenever a object is
inserted (removed or updated) it should trigger a method on the Proxy.
Off course the proxy would do this both ways so that a technical
implementation (e.g. SVG) would add an element it would at this as a
proper TGraphObject to the appropriate TExtGraph instance.

Synchronization options can be set at the Proxy. In case of SVG, one
would probably want the XmlDom to be a reflection off the Graph, meaning
that it must be fully synchronized. Other sollutions may be implemented,
having a one way sync for instance would allow a repository of objects
being available to be drawn.

Here my description stops, since I need to implement this in a
prototype, but I'm convinced this could very well work and allow other
developers to add new technical layers very easily. Additionally,
perhaps needless to say, multiple proxies could allow object translation
on the fly. Having both Graph, SVG and other standards simultaniously...

So far my deep thoughs and ambition.

Marco.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

Re: [Extgraph-developer] The TGraphProxy Idea

[Marco W. <in...@ca...>]

I haven't got much time right now and want to come back on this. In the 
meanwhile let me just finish my proto and send you an email later this 
week (hopefully). I think just by refactoring some code I can show you 
what I have in mind. I do realize that you are abstracting the drawing 
stuff to the svg elements. However this doesn't abstract the data 
definition layer yet. If you continue this way, the SimpleGraph will do 
nothing but offer a bitmap for the svg-elements and you will end up with 
a new layer being implemented behind svg, since any data repository now 
has to create the svg elements and the drawing specifics...

The proxy will solve both since you'll be able to have multiple data 
storage fascilities which all take part in the grand-proces of drawing 
stuff...

Please let me show you later on...

Marco.

vrecion wrote:

>Lively discussion, isn't it? :-)
>That is what I like a lot in OS projects, really.
>I am afraid (but not sure) that there is misunderstanding of SVG idea.
>So excuse me if I will explain something that you are aware of already.
>There are two parts of SVG:
>- first is way, how data are stored in streams or files. Here SVG can be one
>of the more formats.
>- second is the way of in memory objects representation
>
>I will discuss only the second part.
>We have several graph objects that has different graphical representations.
>They are nodes of same class:
>- TpolygonalNode
>- TrectangularNode
>- TroundRectangularNode
>- TroundRectangularNode
>- TellipticNode
>- TtriangularNode
>- TrhomboidalNode
>- TpentagonalNode
>
>There are also links, connecting nodes, but I will leave them aside for a
>while.
>
>Idea is to remove all nodes and replace them with SVG node that will have
>xml element where graphical shape is stored.
>Where are advantages of such approach?
>Imagine that you would need to add other shape for example cylinder for
>graphical representation of database. You will have to create another object
>called say TcylinderNode and to implement it.
>In the case of SVG you will just supply different xml during node creation,
>without touching core classes.
>With svg node other shapes (like box with circles for firewall) are really
>easy to achieve.
>Some examples:
>Rectangular node is svg node with following xml:
><g id="1">
> <rect x="1" y="1" width="1198" height="398"/>
> <text x="20" y="20">This is rectangle</text>
></g>
>In fact svg graph object works with dom, so node shape can be created
>programatically either by parsing text or creating xml nodes like:
>SomeObject.SVG.AddChild(SVG.Document.createElement('rect').setAttribute('x',
>'1')); ...
>
>Another example:
><g id="2" width="300" height="300">
> <circle cx="150" cy="50" r="40" stroke="black" stroke-width="2"
>fill="bisque"/>
> <line x1="150" y1="90" x2="150" y2="200" stroke-width="2"/>
> <line x1="150" y1="200" x2="100" y2="300" stroke-width="2"/>
> <line x1="150" y1="200" x2="200" y2="300" stroke-width="2"/>
> <line x1="150" y1="120" x2="100" y2="200" stroke-width="2"/>
> <line x1="150" y1="120" x2="200" y2="200" stroke-width="2"/>
></svg>
>This xml processed by SVG node draws figure used as an Actor in UML
>diagrams.
>
>Equally straightforward is creation of specialized nodes. For example nodes
>storing data and processing them. Say that you need special node that will
>store and display integer value.
>You will the write something like this:
>
>TmyNode = class(TSVGNode)
>Private
> Function getMyInt:Integer;
> Procedure setMyInt(i:Integer);
>Property
> MyInt:Integer read getMyInt write setMyInt; 
>End;
>
>....
>Function TmyNode.getMyInt:Integer;
>Begin
> If SVG.FirstTag('data')<>nil
>  Then Result:=SVG.FirstTag('data').AsInteger //suppose that you decided to
>store your data in element with data tag
>  Else Result:=-1; // default value
>End;
>
>Procedure TmyNode.setMyInt(i:Integer);
>Begin
>If SVG.FirstTag('data')<>nil
>  Then SVG.FirstTag('data').AsInteger:=i 
>  Else SVG.AddChildElement('data').AsInteger:=i;  // create element and fill
>value
>End;
>
>
>That is why there is svg code in current nodes, i.e. because of backward
>compatibility. But I agree that it makes code complex (I promise - will try
>to find another way to get both clener code and backward compatibility)
>
>Pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of Marco
>Wobben
>Sent: Tuesday, March 08, 2005 2:22 PM
>To: ext...@li...
>Subject: [Extgraph-developer] The TGraphProxy Idea
>
>Hi guys,
>
>I've joined the SimpleGraph developers group to be able to implement
>features in the Graph library for a specific graph library purpose. I
>need it to display information from a repository and not have it any
>other way. The link between stored information and the visual
>representation requires identification and information to be portable to
>and from the graphs. For this sollution I think a TGraphProxy is
>required. Reading up on several design patterns, I've came to the
>conclusion that this pattern is the way to go for this issue.
>
>This would solve another issue I commented on earlier, SVG
>implementation within the main source and baseclasses. I'm still working
>on a first draft and hope to get it working sometime soon. Implementing
>such a sollution has a personal high priority. Extracting technically
>specific code implementation (like SVG, but also in my case other
>standards) would bring back the focus where it should be. Focus on SVG
>in the SVG code and focus for TExtGraph in the graph code. (And needless
>to say I can focus on other standards without complaining or having to
>worry too much about IFDEFs and other code implementations I do not
>require.)
>
>So what about this so called TGraphProxy? The answer I'm given is
>partially based upon my finding in the current SVG code and partially on
>my 'not implemented yet' needs. What I can see in the Graph classes are
>the following items:
>
>- GraphObjects are identified.
>- GraphObjects have properties.
>- GraphObjects are added, removed and updated.
>
>The internals of TGraph(Objects) perform all these actions, and specific
>descendant classes add functionality for a specific display feature. My
>idea is to have the above list of functionality published to an external
>component, a Proxy. A TExtGraph would have a publised property which is
>to be a component link to a TCustomGraphProxy. Whenever a object is
>inserted (removed or updated) it should trigger a method on the Proxy.
>Off course the proxy would do this both ways so that a technical
>implementation (e.g. SVG) would add an element it would at this as a
>proper TGraphObject to the appropriate TExtGraph instance.
>
>Synchronization options can be set at the Proxy. In case of SVG, one
>would probably want the XmlDom to be a reflection off the Graph, meaning
>that it must be fully synchronized. Other sollutions may be implemented,
>having a one way sync for instance would allow a repository of objects
>being available to be drawn.
>
>Here my description stops, since I need to implement this in a
>prototype, but I'm convinced this could very well work and allow other
>developers to add new technical layers very easily. Additionally,
>perhaps needless to say, multiple proxies could allow object translation
>on the fly. Having both Graph, SVG and other standards simultaniously...
>
>So far my deep thoughs and ambition.
>
>Marco.
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>  
>

RE: [Extgraph-developer] Status

[vrecion <pav...@sy...>]

There are some dependencies:
- JEDI JCL/JVCL declares support for Delphi 5-2005, but I think that it
should work also in 3-4 versions.
- XML Partner declares nothing, but it should work on all Delphi =
versions.

Testing on all Windows versions is maybe too extensive.=20
Maybe 95 or 98 and 2000 or XP should be sufficient. Demo applications =
can be
OS sensitive, but with egGraph package the risk is low.
What's your opinion?

Pavel

-----Original Message-----
From: Stefan Melis [mailto:ste...@po...]=20
Sent: Tuesday, March 08, 2005 4:21 PM
To: vrecion
Subject: RE: [Extgraph-developer] Status

I think it's a good idea if there's one person who handles the releases =
on
the SF pages.
I will be very busy the next month or 2 so I won't be able to develop =
very
much, but I would still like to contribute as much as I can, if that =
means
doing stupid things, I'll do the stupid things ;)

I think that, before we release anything, we should at least test with:

Delphi 3 through 7 (I have 3, 5 and 7 already installed; and have a copy =
of
4 around somewhere...)
Windows 95, 98, 2000, XP, 2003. I've got an XP, 2000 and 2003 machine =
ready
for testing.

I wouldn't mind doing all the tests, but I'll have to do an install on =
an
old machine for 95/98 tests.

Anything else we should do?

Stefan



-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 14:31
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status

Who will take care about release?
If you like, I can do it, or if Stefan wants ...?.
What we should do/test/check before release?

pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Stefan
Melis
Sent: Tuesday, March 08, 2005 12:14 PM
To: ext...@li...
Subject: RE: [Extgraph-developer] Status

As I understand it, the CVS release is the same as the package Marco
distributed to us earlier. Is that right?
With regard to the release:
I don't think the BezierLink is reade for release as the DrawText
implementation is not correct yet. It draws the text as if it were a =
normal
TGraphLink. I posted a question about that earlier. What should we do =
with
that?

Other than that I don't see any problems with releasing a beta with the
updates that we have so far.

Stefan=20

ps. Sorry Pavel for the double mail :)

-----Oorspronkelijk bericht-----
Van: ext...@li...
[mailto:ext...@li...] Namens vrecion
Verzonden: dinsdag 8 maart 2005 11:31
Aan: ext...@li...
Onderwerp: RE: [Extgraph-developer] Status


Well, with the release I am not quite sure, while there is not ready
important stuff - save/load of graphs.

I do not quite understand TgraphProxy. Can you explain it a little?

Thanx

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of =
Marco
Wobben
Sent: Tuesday, March 08, 2005 11:07 AM
To: ext...@li...
Subject: Re: [Extgraph-developer] Status

Looks good to me. I've got additional work ready, do you wish to release
this first as a new version and write some release info about the new =
stuff?

Good enough to release:
- HotTrack
- InsertPoint, RemovePoint in the TGraphLink class
- Fixes to BezierLink
- TCurvedLink (Quadratic Bezier)

Work in progress is:
- TGraphProxy (for external objects identification and information. E.g.

SVG or other repository formats, like I use in CaseTalk) Reference used =
for
implementation is the design pattern book in our bookshelve. I think =
this
will work very well and greatly extend the usability for the Graph
library... ;) Ok, I'm a bit more enthousiastic because it may very well
allow multiple proxies which enable it to work as a translation library =
as
well (on the fly). More on the subject later.

Regards,
Marco.

vrecion wrote:

>I have distributed packages to cvs.
>Check it, try it, pls. Let me know.
>Pavel
>
>-----Original Message-----
>From: ext...@li...
>[mailto:ext...@li...] On Behalf Of=20
>Marco Wobben
>Sent: Monday, March 07, 2005 11:43 AM
>To: ext...@li...
>Subject: [Extgraph-developer] Status
>
>Hi guys,
>
>It's been silent for a few days and I am wondering how things are
going.=20
>I realize the code may very well be in the hands of Stefan and I'm=20
>contuing stuff on the multipoint links. If so, please let me know what=20
>to do with some of the new methods and fixes I've made. For now I still

>have a working copy and could simply send it by mail, yet I'd like to=20
>hear how things are going or where it's not going at all... ;)
>
>Marco.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid=20
>reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide Read honest & candid=20
>reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>_______________________________________________
>Extgraph-developer mailing list
>Ext...@li...
>https://lists.sourceforge.net/lists/listinfo/extgraph-developer
>
>
>
> =20
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&opLk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid =
reviews
on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

RE: [Extgraph-developer] The TGraphProxy Idea

[vrecion <pav...@sy...>]

Lively discussion, isn't it? :-)
That is what I like a lot in OS projects, really.
I am afraid (but not sure) that there is misunderstanding of SVG idea.
So excuse me if I will explain something that you are aware of already.
There are two parts of SVG:
- first is way, how data are stored in streams or files. Here SVG can be one
of the more formats.
- second is the way of in memory objects representation

I will discuss only the second part.
We have several graph objects that has different graphical representations.
They are nodes of same class:
- TpolygonalNode
- TrectangularNode
- TroundRectangularNode
- TroundRectangularNode
- TellipticNode
- TtriangularNode
- TrhomboidalNode
- TpentagonalNode

There are also links, connecting nodes, but I will leave them aside for a
while.

Idea is to remove all nodes and replace them with SVG node that will have
xml element where graphical shape is stored.
Where are advantages of such approach?
Imagine that you would need to add other shape for example cylinder for
graphical representation of database. You will have to create another object
called say TcylinderNode and to implement it.
In the case of SVG you will just supply different xml during node creation,
without touching core classes.
With svg node other shapes (like box with circles for firewall) are really
easy to achieve.
Some examples:
Rectangular node is svg node with following xml:
<g id="1">
 <rect x="1" y="1" width="1198" height="398"/>
 <text x="20" y="20">This is rectangle</text>
</g>
In fact svg graph object works with dom, so node shape can be created
programatically either by parsing text or creating xml nodes like:
SomeObject.SVG.AddChild(SVG.Document.createElement('rect').setAttribute('x',
'1')); ...

Another example:
<g id="2" width="300" height="300">
 <circle cx="150" cy="50" r="40" stroke="black" stroke-width="2"
fill="bisque"/>
 <line x1="150" y1="90" x2="150" y2="200" stroke-width="2"/>
 <line x1="150" y1="200" x2="100" y2="300" stroke-width="2"/>
 <line x1="150" y1="200" x2="200" y2="300" stroke-width="2"/>
 <line x1="150" y1="120" x2="100" y2="200" stroke-width="2"/>
 <line x1="150" y1="120" x2="200" y2="200" stroke-width="2"/>
</svg>
This xml processed by SVG node draws figure used as an Actor in UML
diagrams.

Equally straightforward is creation of specialized nodes. For example nodes
storing data and processing them. Say that you need special node that will
store and display integer value.
You will the write something like this:

TmyNode = class(TSVGNode)
Private
 Function getMyInt:Integer;
 Procedure setMyInt(i:Integer);
Property
 MyInt:Integer read getMyInt write setMyInt; 
End;

....
Function TmyNode.getMyInt:Integer;
Begin
 If SVG.FirstTag('data')<>nil
  Then Result:=SVG.FirstTag('data').AsInteger //suppose that you decided to
store your data in element with data tag
  Else Result:=-1; // default value
End;

Procedure TmyNode.setMyInt(i:Integer);
Begin
If SVG.FirstTag('data')<>nil
  Then SVG.FirstTag('data').AsInteger:=i 
  Else SVG.AddChildElement('data').AsInteger:=i;  // create element and fill
value
End;


That is why there is svg code in current nodes, i.e. because of backward
compatibility. But I agree that it makes code complex (I promise - will try
to find another way to get both clener code and backward compatibility)

Pavel

-----Original Message-----
From: ext...@li...
[mailto:ext...@li...] On Behalf Of Marco
Wobben
Sent: Tuesday, March 08, 2005 2:22 PM
To: ext...@li...
Subject: [Extgraph-developer] The TGraphProxy Idea

Hi guys,

I've joined the SimpleGraph developers group to be able to implement
features in the Graph library for a specific graph library purpose. I
need it to display information from a repository and not have it any
other way. The link between stored information and the visual
representation requires identification and information to be portable to
and from the graphs. For this sollution I think a TGraphProxy is
required. Reading up on several design patterns, I've came to the
conclusion that this pattern is the way to go for this issue.

This would solve another issue I commented on earlier, SVG
implementation within the main source and baseclasses. I'm still working
on a first draft and hope to get it working sometime soon. Implementing
such a sollution has a personal high priority. Extracting technically
specific code implementation (like SVG, but also in my case other
standards) would bring back the focus where it should be. Focus on SVG
in the SVG code and focus for TExtGraph in the graph code. (And needless
to say I can focus on other standards without complaining or having to
worry too much about IFDEFs and other code implementations I do not
require.)

So what about this so called TGraphProxy? The answer I'm given is
partially based upon my finding in the current SVG code and partially on
my 'not implemented yet' needs. What I can see in the Graph classes are
the following items:

- GraphObjects are identified.
- GraphObjects have properties.
- GraphObjects are added, removed and updated.

The internals of TGraph(Objects) perform all these actions, and specific
descendant classes add functionality for a specific display feature. My
idea is to have the above list of functionality published to an external
component, a Proxy. A TExtGraph would have a publised property which is
to be a component link to a TCustomGraphProxy. Whenever a object is
inserted (removed or updated) it should trigger a method on the Proxy.
Off course the proxy would do this both ways so that a technical
implementation (e.g. SVG) would add an element it would at this as a
proper TGraphObject to the appropriate TExtGraph instance.

Synchronization options can be set at the Proxy. In case of SVG, one
would probably want the XmlDom to be a reflection off the Graph, meaning
that it must be fully synchronized. Other sollutions may be implemented,
having a one way sync for instance would allow a repository of objects
being available to be drawn.

Here my description stops, since I need to implement this in a
prototype, but I'm convinced this could very well work and allow other
developers to add new technical layers very easily. Additionally,
perhaps needless to say, multiple proxies could allow object translation
on the fly. Having both Graph, SVG and other standards simultaniously...

So far my deep thoughs and ambition.

Marco.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Extgraph-developer mailing list
Ext...@li...
https://lists.sourceforge.net/lists/listinfo/extgraph-developer

[Extgraph-developer] The TGraphProxy Idea

[Marco W. <in...@ca...>]

Hi guys,

I've joined the SimpleGraph developers group to be able to implement
features in the Graph library for a specific graph library purpose. I
need it to display information from a repository and not have it any
other way. The link between stored information and the visual
representation requires identification and information to be portable to
and from the graphs. For this sollution I think a TGraphProxy is
required. Reading up on several design patterns, I've came to the
conclusion that this pattern is the way to go for this issue.

This would solve another issue I commented on earlier, SVG
implementation within the main source and baseclasses. I'm still working
on a first draft and hope to get it working sometime soon. Implementing
such a sollution has a personal high priority. Extracting technically
specific code implementation (like SVG, but also in my case other
standards) would bring back the focus where it should be. Focus on SVG
in the SVG code and focus for TExtGraph in the graph code. (And needless
to say I can focus on other standards without complaining or having to
worry too much about IFDEFs and other code implementations I do not
require.)

So what about this so called TGraphProxy? The answer I'm given is
partially based upon my finding in the current SVG code and partially on
my 'not implemented yet' needs. What I can see in the Graph classes are
the following items:

- GraphObjects are identified.
- GraphObjects have properties.
- GraphObjects are added, removed and updated.

The internals of TGraph(Objects) perform all these actions, and specific
descendant classes add functionality for a specific display feature. My
idea is to have the above list of functionality published to an external
component, a Proxy. A TExtGraph would have a publised property which is
to be a component link to a TCustomGraphProxy. Whenever a object is
inserted (removed or updated) it should trigger a method on the Proxy.
Off course the proxy would do this both ways so that a technical
implementation (e.g. SVG) would add an element it would at this as a
proper TGraphObject to the appropriate TExtGraph instance.

Synchronization options can be set at the Proxy. In case of SVG, one
would probably want the XmlDom to be a reflection off the Graph, meaning
that it must be fully synchronized. Other sollutions may be implemented,
having a one way sync for instance would allow a repository of objects
being available to be drawn.

Here my description stops, since I need to implement this in a
prototype, but I'm convinced this could very well work and allow other
developers to add new technical layers very easily. Additionally,
perhaps needless to say, multiple proxies could allow object translation
on the fly. Having both Graph, SVG and other standards simultaniously...

So far my deep thoughs and ambition.

Marco.