RE: [gef-dev] 2.2 suggestion: Draw2D LayoutManagers as decorators

["Scott Stanchfield" <scott@xxxxxxxxxxxx>]

I'd recommend you read my article "Effective Layout Management". While it's
an AWT/Swing based article, the nesting concepts it talks about are equally
applicable for SWT.

The trick is "nesting" your layouts to do what you're asking. (SWT layouts
have one *big* advantage over AWT layouts, though; they allow "hints" to be
passed when computing the preferred size of a layout. Very nice...)

See
http://developer.java.sun.com/developer/onlineTraining/GUI/AWTLayoutMgr

I also have some slides for this that I presented at JavaOne a few years ago
that are a bit more up-to-date -- see http://javadude.com/articles, JavaOne
Talks, Effective Layout Management

Hope this helps,
-- Scott

====================
Scott Stanchfield
FGM, Inc.
scotts@xxxxxxx
====================

> -----Original Message-----
> From: gef-dev-admin@xxxxxxxxxxx [mailto:gef-dev-admin@xxxxxxxxxxx]On
> Behalf Of Richard Clark
> Sent: Thursday, May 01, 2003 12:58 PM
> To: gef-dev@xxxxxxxxxxx
> Subject: [gef-dev] 2.2 suggestion: Draw2D LayoutManagers as decorators
>
>
> As I've worked on several editors, I've run into limitations in
> the Draw2D layout and LayoutManager classes. In particular, there
> are times I'd like to restrict a layout to a specific area of the
> screen (a la XYLayout), but let the individual components arrange
> themselves (a la DelegatingLayout.)
>
> Some layouts stand alone, while others have associated layout
> managers (and only work with those managers). This can make it
> difficult to choose an appropriate layout or to use the layout
> manager of one's choice. So I'd like to suggest a refactoring of
> the Layout code to use "decorators":
> 1. Allow a Layout to have a chain of Layout Managers, ending in a
> default "null" manager contained within AbstractLayout (replace
> setLayoutManager with addLayoutManager / removeLayoutManager)
> 2. replace (or extend) setConstraint with boolean
> addConstraint(IFigure, Object) & removeConstraint(IFigure,
> Object). These calls would be chained, and could "consume" the
> constraint (by returning true) in which case the chain ends.
> Unconsumed constraints could be caught by the null layout manager
> and either be swallowed silently (returning false at the top
> level) or raise an exception.
>
> This would move us a long way toward having "toolkits" of layout
> managers that could be composed together to get the desired
> effect (as in the "arrange yourselves within this rectangle" example).
>
> ..Richard
>
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/gef-dev
>
>