[isabelle-dev] NEWS: Dockable window "Find"

[Holger Gast]

>> FlowLayouts invariably compute their preferred size
>> in one line. However, when later they are asked to
>> layout the children of their container, they break
>> them into lines and thus use up more vertical space
>> than advertised originally. As a result, components
>> in the later lines may be partly obscured when
>> re-sizing windows.
> 
> From that explanation, the WrapLayout from above should not work, despite
> relatively enthusiastic answers on that blog spot.
Interesting! One learns something new whenever one uses any API :)

My explanation is actually merely a synopsis of the official explanation:

http://docs.oracle.com/javase/tutorial/uiswing/layout/howLayoutWorks.html

There it is stated explicitly:
>The end result is that to determine the best size for the
>container, the system determines the sizes of the containers at
>the bottom of the containment hierarchy. These sizes then
>percolate up the containment hierarchy, eventually determining
>the container's total size.
Also, none of the standard layout managers look at the container's
size, substantiating the above idea.
(see also http://docs.oracle.com/javase/tutorial/uiswing/layout/custom.html
for explanations on how a custom layout manager is supposed to behave.)

> On Linux / Nimbus its takes some time to converge, depending on the number of
> results.  I think it was faster on Mac OS X this afternoon, or that
> machine was just faster.
This observation also indicates that layouting is really
not meant to depend on the containers' sizes and to use
the internal side-effect described below ;(

So here is why WrapLayout happens to work: by going through the
Swing/AWT code, I found that "setSize()" (called in the top-down phase
of the layout) actually invalidates the current component (and its
parents, this is why some iteration is occurs) when the  size changes.

So in the end, the same thing occurs in both solutions:
the container is re-layouted. While WrapLayout relies for
some internal, undocumented behaviour, I proposed to fire
the re-layout explicitly.

Well, one more piece of information about Swing gathered.
(Not very useful though: like many people nowadays, I have
switched to the much faster and more modern SWT/JFace for
my projects anyway.)

Cheers,

Holger

PS: May I ask: if you just plug in my layout manager (just replace
new WrapLayout() with new RetriggeringFlowLayout()), does
it also take the same amount of time to converge?
I believe it should, but some Swing optimizations may kick in
since I schedule the re-layout by SwingUtilities.invokeLater().
Would be just interesting to know.