Michael, I think I understand what you are saying. Currently, in Piccolo there are parts that would not work if everything were a JComponent. I'll accept that fact for the time being.
Devs, you'll have to forgive me, because I have more questions about the design of the library. I am trying to understand why Piccolo is designed the way it was - why it has its own event system instead of participating in the Java Swing event system. Is there some pitfall that I have missed? I have been reading Filthy Rich Clients <http://filthyrichclients.org/> a book about Graphics2D and Swing. It is a basic explanation of how graphics and interaction work in Java. It has been what has spurred my questions. I should also state my bias. I am working on application that needs more than traditional GUI components or drawn shapes. Every piece of geometry needs to have the ability to be a control. Controls need to be able to laid out on graphs. If you scrub ahead to 1:34 in our overview video<http://czsaw.iat.sfu.ca/videos/CZSawViews.mp4>, you'll see what I mean. Instead of having a graph laid out of rectangles, I need each of these rectangles to have the ability to respond to events. They need to participate in native drag'n drop operations. To me, Piccolo2D could be more tightly integrated into Java Swing (you would have to do something different for SWT and other widget toolkits) if it had something like: - Every node has in its hierarchy a JComponent. If one works from this design decision, designing interactive components that play well with the rest of Swing would be much easier. We could depend on the JComponent hierarchy as the scene graph to handle picking and rendering. Piccolo does this on its own right now. PCanvases would be the base class. It would be a container for controls similar to a JPanel, except that it wouldn't just layout widgets. It would support panning and zooming of all of its children. I would like to hookup property change listeners, action performed listeners and the like to any and all components. Is there a design principle that guides Piccolo that says this a bad idea and infers the current design? On Wednesday, May 9, 2012 2:21:19 PM UTC-7, Michael Heuer wrote: > > 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
