| Re: [albireo-dev] Updated RelayoutExampleView |
Bruno Haible wrote:
While thinking about this issue, I also noticed a thinko regarding the inhibitSizePropagationToAWT mechanism. Namely, it did not consider the case that an SWT layout operation, on behalf of a SwingControl, could set the size of other SwingControl. But this is precisely what happens in the new RelayoutExampleView. The fix is to generalize inhibitSizePropagationToAWT as follows.
If we have two separate SWT shells with embedded AWT components, then won't the static counter cause resizing in one window to interfere with resizing in the other?
But more importantly, and before we go any farther with more changes, as I said earlier, 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.