[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [albireo-dev] inhibitSizePropagationToAWT
|
Bruno Haible wrote:
Gordon Hirsch wrote:
On Windows, I'm currently seeing no size propagation to AWT. Frequently,
this has the result seen in the attached screenshots.
The reason is a race condition between the code in SwingControl and the
following piece of code from the end of the SWT_AWT.new_Frame method:
...
It calls swingControl.getClientArea() at a moment when this is still 64x64
and pushes this size later to the frame, overwriting the 103x130 bounds that
were set by the SwingControl code.
First, let me make sure I understand.
1) SWT_AWT.new_Frame is called. It schedules the code that will set
frame size.
2) The Swing contents of SwingControl are created and it decides what
the preferred sizes are. It updates the cached values and notifies the
SWT side about the change (which involves a Display.asyncExec().
3) The code scheduled in (1) is run which sets the frame size. At this
point the composite is still 64x64 and this is the size used for the frame.
Correct?
I believe this has always happened (at least on Windows), but we have
not noticed it because there is now a missing final step:
4) The notification from (2) takes place. The appropriate layout() is
done to resize the SwingControl, which, in turn, resizes the frame to
the proper value (not 64x64).
(4) is not happening today because of the inhibitSizePropagation flag.
As it stands now, this flag will prevent any layout() done by the
preferredSizeChanged() method. layout() calls setBounds(), but the size
change is not passed on to AWT because the flag is true.
I don't completely understand the purpose of the flag, but somehow it
has to allow the layout() call to have an effect. No matter what else we
do, this problem needs to be solved.
Now, it would also be nice to prevent the first, useless call to
frame.setSize() that is initiated by SWT_AWT. I can easily believe that
it would cause flicker. But this is a cosmetic fix, and the missing step
(4) is a bigger problem.
Given what we now know, it's probably a bad idea for SWT_AWT to be
setting the frame size at all. In the long run, we may want to ask for
its removal?
