Thomas DeWeese wrote:
Do you think this refactoring would allow the JGVTComponent to render a GVT tree created by hand (not attached to any SVG document)?
So I think the majority of the work in making a dynamic GVT component would be moving some pieces from the JSVGComponent down into the JGVTComponent (most notably the UpdateManager, and the associated repaint infrastructure). In other words this would be almost all refactoring of existing code - I would have to spend a lot more time looking at class dependencies to know exactly how complex the refactoring is. My gut feeling is that the refactoring would not be terribly complex and would likely improve the structure of the Batik components.
The JGVTComponent can already do this (render a GVT tree created by hand). It currently doesn't support dynamic updates of that tree.
If so, then I'd like to give it a try to compare it with my current graphics node system (Jazz).
Ok, what do you need to know?
I would move the RepaintManager, and UpdateManager to the GVT package, and break any dependencies on the bridge package. The UpdateManager will likely need to be split (make a GVTUpdateManager), some fancy footwork could I think avoid this, as most of the UpdateManager dependencies on the bridge package appear to be fairly shallow but because a fair number of people use the UpdateManager I would want to at least keep a proxy in bridge anyways. So as long as we need a class there might as well just keep the bridge dependent parts in it.
I think if you can move these two classes to the GVT package you are 1/3 of the way there. You should run regard at this point and make sure everything still works.
Next you need to start moving stuff from JSVGComponent to JGVTComponent. The simple rule of thumb is if the method references UpdateManager it needs to be moved to JGVTComponent (this is a lot of methods). The biggest exception to this rule is methods that call things like dispatchSVGScrollEvent.
You will also need to move the concept of at least 'dynamic' vs 'static' GVT Tree's to the JGVTComponent - I would probably take the path of least resistance and also move the concept of 'interactive' to JGVTComponent.
The trickiest piece of this will be dealing with the 'nextUpdateManager' stuff which to be quite honest I can't quite figure out the utility of :) The basic idea is to associate an updateManager with the canvas while loading a new document - presumably so if something goes wrong we haven't killed the previous updatemanager but I don't see this working the way things are right now.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
