Prepare SwingLayoutNode for distribution

[mro]

Originally reported on Google Code with ID 150

My colleagues and I also saw a need for a Swing-like layout solution for
Piccolo2D, so we wrote an adapter that actually uses a swing layout manager
to arrange Piccolo nodes.  I've attached the entire implementation and
example usage in SwingLayoutNode.java.  Let's discuss whether this should
be included in the upcoming Piccolo 1.3 release.

Sample using Swing's FlowLayout:
        SwingLayoutNode flowLayoutNode = new SwingLayoutNode( new
FlowLayout() );
        flowLayoutNode.addChild( new PText( "1+1" ) );
        flowLayoutNode.addChild( new PText( "2+2" ) );

Sample using Swing's BorderLayout:
        BorderLayout borderLayout = new BorderLayout();
        borderLayout.setHgap( 10 );
        borderLayout.setVgap( 5 );
        SwingLayoutNode borderLayoutNode = new SwingLayoutNode( borderLayout );
        borderLayoutNode.addChild( new PText( "North" ), BorderLayout.NORTH );
        borderLayoutNode.setAnchor( Anchor.CENTER );
        borderLayoutNode.addChild( new PText( "South" ), BorderLayout.SOUTH );
        borderLayoutNode.setAnchor( Anchor.WEST );
        borderLayoutNode.addChild( new PText( "East" ), BorderLayout.EAST );
        borderLayoutNode.addChild( new PText( "West" ), BorderLayout.WEST );
        borderLayoutNode.addChild( new PText( "CENTER" ),
BorderLayout.CENTER );

I'm also attaching a screenshot of the sample main() for your convenience.

Thanks,
Sam Reid

Reported by samrreid on 2009-12-01 20:12:54

---

• Attachment: SwingLayoutNode.java

[mro]

On Dec 1, Michael Heuer wrote:

I think this is cool, and a good fit for piccolox.swing in extras.
Could you create an issue for this?  With the proper license header,
unit tests, checkstyle fixes, and refactoring of the example into a
separate class, this could go into 1.3.

   michael 

Reported by samrreid on 2009-12-01 20:13:45

[mro]

See this thread for context:

http://groups.google.com/group/piccolo2d-users/browse_thread/thread/741bca3c0aa2d96e?pli=1

Reported by samrreid on 2009-12-01 20:14:27

[mro]

Chris suggested that we also spend some additional time to verify that (1) we're not
exposing anything that we'll regret later, and (2) method names are logical.  I agree
that we need to make sure the public API is acceptable before publishing this.

Reported by samrreid on 2009-12-01 20:16:15

[mro]

I don't have plans for working on this in the near future, if someone wants to work
on it.  Here's a quick itemized summary of proposed work:

1. Add to SVN in piccolox
2. Add license header
3. Add unit tests
4. Add checkstyle fixes
5. Refactor sample usage to separate class
6. Make sure public interface is acceptable
7. Make sure private internal method naming, etc is acceptable

Reported by samrreid on 2009-12-01 20:18:34

[mro]

I'll do it.

Reported by allain.lalonde on 2009-12-01 20:21:58

• Status changed: Accepted
• Labels added: Type-Enhancement, Priority-Low, Effort-Low, OpSys-All, Toolkit-Piccolo2D.Java, Component-Extras, Milestone-1.3, Usability

[mro]

I'd tried something like this in the past and failed, so I'm very much liking this code.

Reported by allain.lalonde on 2009-12-01 20:26:48

[mro]

I'm looking at the Anchor approach and am wondering if it's too restrictive.

It's basically a fill strategy for whatever bounds the LayoutManager assigns to a
node. It would seem that changing the bounds of the nodes is as valid an approach as
pinning the node to the WEST of the box but the current naming convention doesn't
make it clear that Anchor.FILL might be a valid fill strategy.

Thoughts?

Reported by allain.lalonde on 2009-12-02 20:19:14

[mro]

I would vote to leave as-is for now.  Would you want to mark this one as Fixed, Allain?

Reported by heuermh on 2009-12-15 20:38:05

[mro]

Reported by allain.lalonde on 2009-12-15 20:39:16

• Status changed: Fixed

[mro]

Reported by heuermh on 2009-12-15 20:56:11

• Status changed: Verified