[albireo-dev] Re: populate and size/layout management

[Gordon Hirsch <gordon.hirsch@xxxxxxx>]

Gordon Hirsch wrote:
> You're very fast :-) I was thinking of something a little different.
> Could we automatically call populate() from setBounds() (or some event
> handler)? That would remove the pitfall altogether. It might be tricky.

I tried this (from setBounds()), and it does seem to work. setBounds is 
called during layout, so at first I thought it would be too late to call 
populate. But, actually, populate has to call Display.asyncExec to get 
the swing component created, so it doesn't directly affect layout anyway.

So, I made this change and marked the populate method protected.

I wanted to make sure that this would not break the size and layout 
management code that is in both contributions, so I have now merged that 
code into albireo.core too.

AWT min, max, and preferred sizes are cached in SwingControl, so that 
size can be managed without breaking the threading rules. As in the 
original ILOG contribution, the cache is updated by hooking 
validateTree() and invalidate() methods in the AWT component.

There is one addition from the SAS contribution. AWT components are not 
initially set to a hard coded size. Instead, we wait for the AWT 
component to cache a size, and then we re-layout the SwingControl. This 
reduces flicker when the control is first displayed.

The SAS contribution has a different way to update the cached sizes that 
uses a RepaintManager. Since there was some disagreement about this 
approach (pre-project-creation), I have left it out for now. Eventually, 
I'll try to create a test case that will demonstrate why I think it is 
necessary, and we can talk about it more then. We also need to think 
about the performance of the hooked invalidate() method.

I've also checked in a new view, GridLayoutView, that tests this code. 
The simpler layouts from other examples don't really exercise this new 
code. THe new view arranges a 5 x 4 grid of controls in an SWT 
GridLayout. You can switch back and forth between Swing and SWT to see 
the differences in layout, etc.