Skip to main content

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

Gordon Hirsch wrote:
> >> I don't know of any analogous concept in SWT. It's up to the
> >> application. In effect, eveything is a validation root.
>
> 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.

Looking at what dozens of widgets in Eclipse do, I see tons of explicit
calls to layout(), like this:

                        if (!searchInProgress)
                                goButton.setEnabled(true);
                        if (searchInProgress)
                                goButton.setText(Messages.SearchPart_stop);
                        else
                                goButton.setText(Messages.SearchPart_go);
                        goButton.getParent().layout();

This means that
  - The programmer incorporated the knowledge that 'goButton' changes its
    size when its enabled status or its text changes.
or
  - The programmer tested this code and saw that a layout was missing in
    this case, so he put it here.

This is hard to maintain, no? The programmer is not relying on the
size changes, as reported by the 'goButton' itself.
If the 'goButton' is replaced with another widget that needs more room
depending on different conditions, all the code must be reviewed for
extraneous or missing 'layout()' calls, no?

And this approach does not work well for Albireo, because the modification
of the Swing GUI buttons must be done in the AWT thread, and the layout()
call in the SWT thread.

Some people also call layout() inside of a ControlListener.
Is the ControlListener triggered from a Control when it changes its innards,
and the ControlListener needs to call layout()? Or is the ControlListener
triggered as a effect of calling layout() on its parent?

If there is no clear answer to this, then I'm in favour of keeping the
overridable method in SwingControl, like it is now.

Bruno


Back to the top