Re: [albireo-dev] size/layout platform testing

[Bruno Haible <haible@xxxxxxx>]

Hi Gordon,

> But more importantly, and before we go any farther with more changes, as 
> I said earlier, ...

Yes, you are talking faster than I can evaluate and analyze what you say! :-)
I was still preparing the test of it.

> we are not really preventing infinite propagation anyway: 
> 
> > I realized that the frame resize is
> > happening automatically when the SWT composite is resized. On Windows,
> > this happens in the method Composite.resizeEmbeddedHandle()
> ...
> > All of this makes me ask if we have unnecessary code in SwingControl
> > today. In fact, I can completely remove the setAWTSize method (and calls
> > to it) without affecting any of our examples on both Linux and Windows.
> > 
> > So, if there's a problem with infinite propagation, we are currently not
> > preventing it today (i.e. the inhibit flag is not preventing it). It's
> > not clear if we can or if we need to.
> 
> Today, as best I can tell, the statement about setAWTSize above is still 
> true if I set INITIAL_CLIENT_AREA_WORKAROUND to false.
> 
> I'm concerned we have added complicated code that has little, if any, 
> benefit, and which is not being tested. If we can completely remove 
> setAWTSize(), why don't we? If we are not really preventing infinite 
> propagation (because setBounds() is not called on resize), shouldn't we 
> simplify the code by removing the checks?
> 
> On the other hand, if you can add example code that demonstrates the 
> need for this code, then that's great. You'll have proven that this code 
> is needed and we will have an example that actually exercises it.

Test done now.

* Platforms: I tested Linux/gtk, Win32, MacOSX/Carbon. */motif not tested
  because Linux/motif does not work sufficiently well on my machine and
  I don't have a AIX or HP-UX machine nearby.
  All tests done with Eclipse 3.4M4.

* The "resize flickering" view shows heavy flickering on Gtk and Carbon
  ports, and no flickering on Win32.

* Need of size propagation from AWT to SWT: If I disable the
  part of updateCachedAWTSizes that starts with
     if (mustNotify) ...
  then:
    - On Win32, some parts of the RelayoutExampleView don't display themselves
      at all.
    - On Gtk and Carbon, the size of the controls in RelayoutExampleView
      vary in a discontinuous way depending on the width. See the attached
      two screenshots no-propAWTtoSWT-[12],png.
  Conclusion: This propagation is necessary on all 3 platforms.

* Need of size propagation from SWT to AWT: If I disable the contents of
  handleSetBounds then:
    - On Win32, layouts are not done correctly; see the screenshot
      no-propSWTtoAWT.png.
    - On Gtk and Carbon, this change has no effect. The reason is that
      validate() is called nevertheless, due to an event being executed
      in the AWT event thread. This event is of type COMPONENT_RESIZED and
      comes from the Frame.
  I will therefore disable the propagation from SWT to AWT since it's
  redundant with the COMPONENT_RESIZED event.

Now back to what you were saying:

> When the AWT thread caches its min, max and preferred sizes it is not 
> changing the *actual* size of the frame. So who is? The inhibit flag 
> makes sure that the call to setBounds() during the layout does not do 
> it, and yet we see the COMPONENT_RESIZED events in AWT.
> 
> After a lot of head-scratching, I realized that the frame resize is 
> happening automatically when the SWT composite is resized.

Yes, I must assume that this is the case in the Gtk and Carbon ports.
The low-level SWT handle and the low-level AWT peer of the Frame must be
tied together in a way that resizing the SWT handle also resizes the
Frame and sends a COMPONENT_RESIZED event for it.

> On Windows,  
> this happens in the method Composite.resizeEmbeddedHandle(). This is 
> done separately from the setBounds call, and it is implemented with 
> messages at the native windowing system level.

While this is plausible, the no-propSWTtoAWT.png screenshot shows that
the handleSetBounds is still necessary on this platform.

> All of this makes me ask if we have unnecessary code in SwingControl 
> today. In fact, I can completely remove the setAWTSize method (and calls 
> to it) without affecting any of our examples on both Linux and Windows.

This matches what I saw on Linux, but not on Windows.

> So, if there's a problem with infinite propagation, we are currently not 
> preventing it today (i.e. the inhibit flag is not preventing it). It's 
> not clear if we can or if we need to.

Good point. We should produce an example where this infinite loop actually
occurs, and then fix it by moving the 'inhibit' logic into the opposite
notification (AWT -> SWT).

> On the other hand, if you can add example code that demonstrates the 
> need for this code, then that's great. You'll have proven that this code 
> is needed and we will have an example that actually exercises it.

Yes, I agree.

Bruno