Jeffrey, This is an interesting question. I'm not sure of the
implications of implementing Piccolo2D as a direct extension of Swing
base classes, but as Michael pointed out there's advantage in the
decoupling Piccolo2D from Swing. I would also add that the framework
is much simpler to approach and reason about due to this decoupling.
(The Swing component hierarchy has power but complexities; on the
other hand, the PNode base class is very easy to read and debug.)

Piccolo2D has decent integration with Swing via PSwingCanvas, etc. Is
PSwing not sufficient for what you're after? Is there work that could
be done to improve this integration?

I can't speak immediately to the early design decisions, but I've
found Piccolo2D to be a pretty powerful framework and I've had a lot
of success integrating it into a richer Swing desktop application.

If you do more research or exploration on this question, I'd love to
hear what you learn.


On Wed, May 9, 2012 at 6:04 PM, Jeffrey Guenther
<> wrote:
> 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 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, 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 (
>> Piccolo2D for Processing library uses POffscreenCanvas to integrate
>> with Processing (
>> 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
>> (
>> 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:

Piccolo2D Developers Group:

Reply via email to