[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [albireo-dev] SWT size/layout management
- From: Gordon Hirsch <gordon.hirsch@xxxxxxx>
- Date: Fri, 08 Feb 2008 18:11:22 -0500
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 18.104.22.168 (Windows/20071031)
Bruno Haible wrote:
Gordon Hirsch wrote:
In contrast, Swing's relayout mechanism climbs up to the next "validation root",
i.e. the next component in the ancestors list which is known to isolate size
changes in its children from its parent (i.e. which is known to have constant
size, regardless of its children).
I don't know of any analogous concept in SWT. It's up to the
application. In effect, eveything is a validation root.
You mean, by default, every Composite is a "validation root" (shields its
parent component from size changes among its children)? And if a Composite
does not want to behave that way, it overrides layout():
No, I mean that asking a parent widget to layout() does not generally
happen. It's the user of the widgets rather than the widget
implementations themselves that decide when to force a relayout.
This is why, in the RelayoutExample, the size on the SWT side did not
update itself when one presses the Grow/Shrink buttons. You can play
with these buttons and the "SWT-Layout" button to convince yourself
that calling getParent().layout() is necessary for a good application
getParent().layout() works, but it is not the right solution. It is also
wrong in the one case I used it, and I feel a little guilty for
leading us down the wrong path.
I think I can construct an example that will show why
getParent().layout() is not adequate and why we will have to defer to
the application in this case. I'll try to add it to our examples in the
next day or two.