This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The thing which makes BoxLayouts really useful is the ability to add horizontal or vertical glue or struts (from the Box class) to make other components lay out as wanted. If you have a JPanel with a BoxLayout in the form editor, there is no way to create a glue or strut component.
Those "glues" and "struts" are just simple empty components with minimal, preferred and maximal size properly set. It's quite easy to make them e.g. from JPanel. Glue: min. size [0,0], pref. size [0,0], max. size [32767,32767] Horiz. strut: min. size [w,0], pref. size [w,0], max. size [w,32767] Vert. strut: min. size [0,h], pref. size [0,h], max. size [32767,h] (32767 is max. short number - it means that in given direction JPanel may grow to any size - then it's a glue; constant number makes a strut...) Glue and struct can be even combined (e.g. glue with minimum size). So I think there's no need to hack some special support for javax.swing.Box.
this is a comment from Tom Ball posted on nbui list From: Tom Ball <Tom.Ball@sun.com> Subject: Re: [nbui] compliance to Java L&F Design Guidelines by default To: nbui@netbeans.org Date: Tue, 28 Nov 2000 11:25:28 -0800 [unrelated text deleted -ttran] I actually don't care about support for the BoxLayout, but instead proper support for javax.swing.Box. It isn't listed as a Swing component, yet its use in a form editor is a natural. Drop components inside of a box, then drop glue or strut components between them. Although glue and strut components are defined as having no view, in a form editor they should look like an i-beam for a strut and possible a spring for glue (springs were what NeXTStep used). You want to change the length of a strut? Just drag it longer or shorter. You get the idea. In http://www.netbeans.org/project/www/www-nbbugs/msg02269.html, Tomas Pavek closed an enhancement request for struts and glue, stating that it's equivalent to use JPanels with min, pref and max size methods defined to emulate struts and glue. Aside from this being way too much work and not visually obvious, he misses a basic point: Filler components (struts and glue are fillers) were specifically designed as non-Swing lightweight components to reduce their memory footprint. They are not the same as JPanels, and were created because layout using boxes can create forms with very large footprints. Perhaps I can hack up a quick demo so you can understand how much easier and more intuitive visual editing using boxes can be. The main reason Box was added to Swing was to help IDE vendors by providing a standard for them to work with. [unrelated text deleted -ttran]
Reopen as enhancement, we have this in nice-to-have features list for NB 3.3
Target milestone -> 3.3.1.
*** Issue 23549 has been marked as a duplicate of this issue. ***
Set target milestone to TBD
*** Issue 28617 has been marked as a duplicate of this issue. ***
*** Issue 37934 has been marked as a duplicate of this issue. ***
This makes sense, however with the new layout design support becomes less important. Changing target milestone to future.
You can rob my code from the JDNC incubator. See the class BoxFiller. I'm working on a better version of it with an icon and so on, but it's very easy to use, and you can design some very nice GUIs with it. I basically wrapped javax.swing.Box.Filler as a bean which is what Box uses. Go to https://jdnc-incubator.dev.java.net/ and see the package wadechandler. You might have to get it out of cvs and build it for yourself. I'll be including it in a library for NB in the future, but for now you'll have to make the manifest and jar yourself and add it to NB.
Actually, the first thing really necessary to make some progress on this bug is an option to add GUI components to the palette directly from *project's JDK*, so I don't need to link rt.jar as a separate library just to add javax.swing.Box to the palette. This would allow me drop Box'es with *custom creation code* right onto the form. The visual appearance as displayed by the preview would be inconsistent, but the code generated would be already correct. BTW, here's the workaround: you can use a component's pre-init/post-init code to drop Box'es before/after the component in its parent which has a Box layout. The preview would again be incorrect, however.
Box in palette plus custom creation code is not enough. The GUI builder needs to be able to create an instance of the component to be able to drop it onto the form, no matter you provide your own code for it later. Box is not a JavaBean. But Box itself as an instabce is not very useful. What we talk about here is the Box.Filler class, which is not a bean either - it is created and customized by using the various static methods of the Box class.
Isn't this already resolved? I can add Swing Fillers to BoxLayout.
(In reply to comment #14) > Isn't this already resolved? I can add Swing Fillers to BoxLayout. Yes, you are right. We have support for Box.Filler class since NetBeans 7.0. Thanks for pointing this out.