Thank you for the quick reply. I am familiar with the paper. Unfortunately, it does not address the event handling issues that concern me the most.
What I am trying to understand is why support for Swing components through PSwing requires Swing events to be rerouted through a Piccolo event handler back into the Swing hierarchy. Why not make a PNode a JComponent, so it can be part of the Swing hierarchy? In the header to PSwing.java, the following is written: > We are currently developing Piccolo, a "scenegraph" for use in 2D graphics. > One of our ultimate goals is to support Swing lightweight components > within Piccolo, whose graphical space supports arbitray affine transforms. > The challenge in this pursuit is getting the components to respond and > render properly though not actually displayed in a standard Java component > hierarchy. Why wouldn't we want to put PNodes on a Java component hierarchy? It seems like the problem of supporting Swing components in the scene graph is caused by this design decision. Isn't a JComponent hierarchy already a type of scene graph? If Piccolo were to integrate into the JComponent hierarchy, we could depend on Swing to determine if nodes are picked. We could also handle the events in a more standard Java way instead of having to write event handlers that re-route the events from PNodes. Am I missing something? On Wednesday, May 9, 2012 11:56:41 AM UTC-7, Michael Heuer wrote: > > Jeffrey Guenther wrote: > > > I work on a research project called CZSaw. It is a visual analytics tool > for > > text analysis. We need a pan/zoom library that supports Swing > components, > > handles Java events in a standard way, and plays well with Graphics2D. > > > > I have been digging through Piccolo's API and I have been noticing what > > seems to be a lot of code that duplicates stuff provided by Graphics2D. > Ie. > > graphics contexts? Lines, shapes, etc? Also, as best as I can tell > Piccolo > > implements its own event system that does not play well with Swing > events. > > Would the developers be able to tell me the design rationale for doing > > things this way? Is it a legacy issue? Ie. Graphics2D and things didn't > > exist when it was being written. Is it technical issue? > > Piccolo2D implements a scene graph for zoomable user interfaces (ZUI) > and is based on HCI research at UMD. Much of the design rationale for > Piccolo2D is discussed in the following paper and references therein > > Toolkit design for interactive structured graphics > > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.4155 > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1316870 > http://ssltest.cs.umd.edu/hcil/piccolo/learn/Toolkit_Design_2004.pdf > > > > Why are PNodes not JComponents and handled by the Swing EDT? > > PCanvas is a JComponent. > > There are also non-Swing top level containers, such as > POffscreenCanvas and PSWTCanvas, and a separate Piccolo2D library for > Processing > > https://github.com/heuermh/piccolo2d-processing > > > > I really want to avoid rolling my own library and would like to modify > > Piccolo2D to meet our needs if possible. > > Sounds great, welcome. > > michael > -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
