[piccolo2d-dev] Making Piccolo2D play well with Graphics2D and Java events
Hello, I work on a research project called CZSaw http://czsaw.ca. 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? Why are PNodes not JComponents and handled by the Swing EDT? I really want to avoid rolling my own library and would like to modify Piccolo2D to meet our needs if possible. Thanks, Jeff -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
Re: [piccolo2d-dev] Making Piccolo2D play well with Graphics2D and Java events
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
Re: [piccolo2d-dev] Making Piccolo2D play well with Graphics2D and Java events
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
Re: [piccolo2d-dev] Making Piccolo2D play well with Graphics2D and Java events
Looking through the issue threads, it looks like drag and drop is another issue that is made worse by not making a PNodes JComponents. -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
Re: [piccolo2d-dev] Making Piccolo2D play well with Graphics2D and Java events
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
Re: [piccolo2d-dev] Making Piccolo2D play well with Graphics2D and Java events
Jeffrey Guenther wrote: Sorry, I don't follow. What are you referring to with the top level containers? POffscreenCanvas renders to an offscreen BufferedImage. PSWTCanvas is a SWT component (http://www.eclipse.org/swt/). Piccolo2D for Processing library uses POffscreenCanvas to integrate with Processing (http://www.processing.org). The Android port (which may or may not be public at the moment and with which I honestly don't have much experience) probably uses an Activity (http://developer.android.com/reference/android/app/Activity.html). None of these use Swing, so it wouldn't make much sense to have PNode (or any other part of the scene graph) be a JComponent. PCanvas is a top level container that extends JComponent. PSwing is a PNode that contains a JComponent, but that JComponent is not rooted with the component hierarchy that PCanvas is contained in. michael -- Piccolo2D Developers Group: http://groups.google.com/group/piccolo2d-dev?hl=en
