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

Piccolo2D Developers Group:

Reply via email to