Thomas --
On Wed February 25 2009 5:38:55 am [email protected] wrote: > 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). After I sent this, I started going the SVG-manipulation route (I was hoping I wouldn't have to get into the guts of how SVG works). What I had done was merely read in the SVGDocument for each 'child' file, went through it's child nodes, and imported/added those nodes to the 'parent' SVGDocument then updated the canvas with that document. What I need is for all these graphics to be backed by logic; I would need to, for example, process a mouseClicked, know which 'model object' backs that graphic, and execute code. Using your suggested (or even mine, for that matter), is there any way to 'know' which graphic you are interacting with? In other words, in my example of the bookcase, is there any way to know that someone is clicking on a shelf and be able to track it back to that 'image' or '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'. Cool... I even achieved this with my (probably sub-optimal) way above. > > 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. I deal with these types of things constantly... I'm not scared of addressing this in straight Swing. But if it would involve getting into Bakit code and lower-level libraries, then I'll take your word for it that I don't want to go that way. [snip] > > 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. More of a personal comfort thing I suppose... I can't stand dealing with DOM trees. I get 'lost' in the tree and relationships too easy and takes me a while to debug issues with messed up trees. > 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). I haven't run into any issues yet, since this is proof-of-concept code, but I did run into this in the FAQ and multiple list postings. > 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). Thanks for the heads-up. I've been hijacking a lot of code from the examples on the website for the DOM stuff I was trying, and I think that code address it. > > 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. Great... will look into those. I was dealing primarily with the squiggle app (as that was the only graphical app that worked for me) and didn't see anything that immediately struck out at me. > > 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. Excellent. As long as I can work around the need in my second paragraph, you'll have boosted my confidence in what I'm trying to do. Obviously I'll have to RTFM for the SVG spec, but it sounds like I'm on my way. Thanks for the informative reply; Roberto --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
