Jeffrey Guenther wrote: > 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?
I listed three top level containers for Piccolo2D that don't use Swing. There's also an Android port that doesn't use Swing either. > 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 -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
