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 
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

Reply via email to