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

[Bruno Haible <haible@xxxxxxx>]

¦ I'm committing this new view.

And the results of this new view: When I comment out the condition in
setAWTSize, no endless notification is observed.

When I add a frame.pack() statement however, like this:

                        new JRootPane() {
                            // Keep the sizes cache up to date.
                            // The JRootPane, not the JApplet, is the "validation root",
                            // as determined by RepaintManager.addInvalidComponent().
                            // It is here that we can intercept the relevant
                            // invalidate()/validateTree() calls.
                            protected void validateTree() {
                                super.validateTree();
                                updateCachedAWTSizes(getMinimumSize(), getPreferredSize(), getMaximumSize());
                                frame.pack();
                            }
                        };

then I get
  - On Win32 redisplay problems (area of the controls not redrawn,
    probably because the size is 0x0),
  - On Gtk an endless notification, causes endless flickering.

So frame.pack() is really a bad idea. The current result of the
StubbornResizeView is much better.

It means that the "inhibit" logic with the 'lastValidatedAWTTime' is now
only an optimization that minimizes notification.

> 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?

Good question. But I'm leaning to leave this optimization in. We have the
same visual effects with less code and more notifications, and with more
complex/optimized code that produces less notifications.

Bruno


Index: src/org/eclipse/albireo/core/SwingControl.java
===================================================================
RCS file: /cvsroot/technology/org.eclipse.albireo/org.eclipse.albireo.core/src/org/eclipse/albireo/core/SwingControl.java,v
retrieving revision 1.48
diff -c -3 -r1.48 SwingControl.java
*** src/org/eclipse/albireo/core/SwingControl.java      27 Feb 2008 16:54:11 -0000      1.48
--- src/org/eclipse/albireo/core/SwingControl.java      27 Feb 2008 17:09:45 -0000
***************
*** 452,460 ****
      }
  
      // We have bidirectional size propagation, from AWT to SWT, and from
!     // SWT to AWT. To avoid endless recursion in weird cases (for example,
!     // when the AWT component refuses to accept the size that the SWT
!     // component assigns it), we inhibit propagation in this situation:
      // AWT rootpane.validate() ---> SWT layout() -|->  AWT frame.setBounds.
      //
      // When more than one SwingControl is involved, the situation is more
--- 452,459 ----
      }
  
      // We have bidirectional size propagation, from AWT to SWT, and from
!     // SWT to AWT. To minimize pointless notification, we inhibit propagation
!     // in this situation:
      // AWT rootpane.validate() ---> SWT layout() -|->  AWT frame.setBounds.
      //
      // When more than one SwingControl is involved, the situation is more