| Re: [albireo-dev] inhibitSizePropagationToAWT |
Bruno Haible wrote:
Gordon Hirsch wrote:First, let me make sure I understand. ... I don't completely understand the purpose of the flagLet's look at how bidirectional notification works in general.
...Thanks for the clear explanation. I had a vague idea of this, but your writeup helped. I agree, in general, with the need to cut off propagation sooner rather than later.
You propose to allow this back-propagation, i.e. to stop the notification after 2 rounds.
No, but I now see how my description could have been interpreted that way. I really wanted one round also. Even after reading your response, I was still puzzled about how the current implementation even worked at all since I saw it as not even a full round.
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. 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.
I can't find the equivalent code for Gtk. Perhaps the same thing happens implicitly there.
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.