[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[albireo-dev] Re: populate and size/layout management
- From: Gordon Hirsch <gordon.hirsch@xxxxxxx>
- Date: Sat, 26 Jan 2008 19:59:03 -0500
- Delivered-to: email@example.com
- User-agent: Thunderbird 126.96.36.199 (Windows/20071031)
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.