[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[albireo-dev] Re: populate and size/layout management

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.