DO NOT REPLY [Bug 39451] - Decouple gvt from bridge so clients can build their own graphics node trees

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39451>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39451


deweese@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement




------- Additional Comments From deweese@apache.org  2006-04-30 23:34 -------
So I had some time to look into this yesterday.  I didn't get through
everything but I think I looked at enough to get the gist of things.
In short you tool the basic interface of the GraphicsNode and turned
them into interfaces.  Then the Bridges interact with these interfaces.

   While I'm not dead set against this I would say that this is not
particularly exciting to me.  The whole 'gnode' interface is still
rather large and proper implementation of it would be extremely
difficult (for example all of text layout is done in the GVT tree yet
this must be done properly for complex fills to be calculated properly).

   So there is a non-trivial interaction between the Bridge classes
and the GVT implementation (this only get's worse when you consider
the SVG DOM).  To be honest I'm not interested in trying to debug
across libraries as this would require (it works for GVT because of
'X' but fails for BLAH, but the Bridge should really handle case 'Z'
even though it can't occur with the GVT...)

   Also this would really push the GVT out as a public 'interface' 
meaning that any change to the Bridge<->GVT tree would break 
'external' software - or we would have to add new subinterfaces of 
interfaces that the bridge would check for (Gahhh!).

   Finally, I think that in _most_ cases people could, for less work,
simply subclass our existing GVT classes, and subclass the Bridges
(replacing the 'createGraphicsNode' method) to build a 'custom' GVT
tree (all the above steps are required in the 'gnode' case anyways).

   The only drawback would be for someone who already had a graphics
tree structure that was 'by chance' essentially identical in structure
to the GVT tree.

   I encourage other people to look at it and come to separate
opinions, I'm not dead set against it but I think it would add
significantly to the effort needed to develop Batik and I don't
think there would be significant benefit to Batik.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org