>> 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. _______________________________________________ isabelle-dev mailing list [email protected] https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
