[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [albireo-dev] size/layout management
|
Bruno Haible wrote:
Good. I added some comments and made the getCachedAWTSizes method more
self-contained. (Before, this method was marked 'protected', but it
was only safe to be called when cachedSizesInitialized = true - which
is private. Also, it's safer to evaluate cachedSizesInitialized
in the same 'synchronized(this)' block as the three cache variables.)
Good point.
Still, I haven't understood the handleSetBounds and setAWTSize methods.
These mainly just pass on a newly set size to the embedded component.
Also, is the 'computeSizeDefault' variable really needed? Why not use
'!cachedSizesInitialized' instead? Or equivalently, why is the initial
value of 'computeSizeDefault' false?
Sorry about that. It was an unnecessary hack to remember the state of
the cache when computeSize() was actually called. There is a small
chance for this sequence of events:
1) computeSize() called
2) AWT cache initialized from AWT thread
3) setBounds() called
In this rare case, if we rely on the cachedSizesInitialized field,
setBounds() could pass on a bad (zero) size to AWT. But, after thinking
about it more, this is a very unlikely case, and the only harm is a
little extra flicker as far as I know. So I'm removing the field, and
using cachedSizesInitialzed instead.
I'm checking the flag in a synchronized block, but we could also just
make it volatile.
### Eclipse Workspace Patch 1.0
#P org.eclipse.albireo.core
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.16
diff -u -r1.16 SwingControl.java
--- src/org/eclipse/albireo/core/SwingControl.java 1 Feb 2008 20:55:04 -0000 1.16
+++ src/org/eclipse/albireo/core/SwingControl.java 5 Feb 2008 01:32:00 -0000
@@ -395,14 +395,6 @@
}
}
- // Since the swingComponent is not already initialized in the constructor,
- // this control initially has no notion of what its preferred size could
- // be.
- // This variable is true when computeSize() should use the default
- // implementation from the superclass, and is false once computeSize()
- // can use the cached sizes, coming from the swingComponent.
- private boolean computeSizeDefault = false;
-
protected void setAWTSize(final int width, final int height) {
// System.out.println("Setting size from SWT: " + width + " x " + height + " for " + swingComponent);
EventQueue.invokeLater(
@@ -417,15 +409,22 @@
}
/**
- * Called when the SWT layout assigns a size and position to this Control.
+ * Called when the SWT layout or client code assigns a size and position to this Control.
*/
protected void handleSetBounds(int width, int height) {
assert Display.getCurrent() != null; // On SWT event thread
checkPopulated();
- if (!computeSizeDefault) {
- setAWTSize(width, height);
+ // pass on the desired size to the embedded component, but only if it could
+ // be reasonably calculated (i.e. we have cached preferred sizes).
+ synchronized (this) {
+ // Note: in rare cases it is possible that the cachedSizesInitialized flag may have changed
+ // since computeSize was called. If so, we'll be passing a bad size to the embedded
+ // component. This is not a big problem because the component will be resized again
+ // very quickly (with, possibly, some flicker).
+ if (cachedSizesInitialized) {
+ setAWTSize(width, height);
+ }
}
- computeSizeDefault = false;
}
// This is called by the layout when it wants to know the size preferences
@@ -442,9 +441,7 @@
Dimension max = new Dimension();
boolean initialized = getCachedAWTSizes(min, pref, max);
- computeSizeDefault = !initialized;
-
- if (computeSizeDefault) {
+ if ((!initialized)) {
// System.out.println("Uninitialized AWT sizes for " + swingComponent);
return super.computeSize(widthHint, heightHint, changed);
} else {
