Hi Roberto,
Roberto Villarreal <[email protected]> wrote on 02/24/2009 07:07:47
PM:
> What I need to do:
>
> 1) Add and remove predefined graphical 'widgets' (which are predefined
> SVG files) onto a given background, viewing the end result. Picture
> a bookcase and adding/removing shelves from it, where in straight
> Swing one could merely add/remove JLabels from a JPanel
In SVG you would merely add/remove an 'image' element (or a
'use' element).
> 2) Be able able to use the current zooming functionality of JSVGCanvas
> on the 'background' to have the entire picture zoom at the same rate
> (i.e. the bookcase as well as the shelves resize).
> Optionally/preferrably an attempt to zoom one of the 'children' (i.e.
> shelf) would redispatch the zoom attempt back up to the parent.
If you add an image element for each 'child' then you will get
this behavior 'for free'.
> I'm at probably an intermediate level with Swing, but very new to
> Batik (as of about 12 hours ago) and SVG; the closest I've come is to
> have everything zoom correctly when in the process of zooming, but
> once the mouse is released, the background is correctly zoomed, but
> the children revert back to their previous sizes and positions.
Congratulations, I'm not sure I could get that working in that
time frame... I think this is dead end. Once you get things to
zoom you will have to worry about event targeting and things would
just get messy.
> Is my strategy of mainting a parent/child hierarchy through Swing a
> bad strategy? Or if not, what am I missing?
I think so. Nothing I think.
> The other strategy would be to work with only one JSVGCanvas and
> manipulating the SVG for it on the fly; however, because of the
> need to manipulate it constantly, it seems like an error-prone
> thing to do.
This is exactly the way to go, this is what Batik is built to
handle. I'm not sure why adding/removing an SVG image element to
the document tree would be more error prone than adding/removing
Swing elements to the widget hierarchy.
Really the two are similar. The main 'gotcha' for dynamic
manipulation of an SVG document is to make sure you only change
the document in the UpdateManager's RunnableQueue (which is just
like the swing rule to only change components in the Swing event
thread).
The other common problems tend to be with the namespacing
of elements (SVG elements have to be in the SVG namespace,
most SVG attributes should be in the null namespace, with the
exception of the 'xlink' attributes (like xlink:href) which
need to be in the xlink namespace).
> The only posting I've come across that is close to mine went with the
latter
> method, but possibly because that's what the user had started with.
> Suggestions or pointers?
If you look in the samples directory there are many examples
of manipulating an SVG document on the fly. Most of these are
written using JavaScript but 'porting' the basics over to Java
is pretty simple.
> Or am I trying to use the wrong tool for the job?
Actually, given what you have described I think Batik is
the perfect tool for the job.
