zartc wrote:IMHO Swing Designer does NOT includes full support for MigLayout as you boldly advertise.
We stand by that statement and believe that we provide full round-trip editing and rendering support for MiGLayout. All MiGLayout features should parse and render properly in the design view, and we provide graphical and property pane support for all of the significant MiGLayout features. For the more esoteric MiGLayout feature, you can either set them via editing the constraints in the property pane or in the source view. Any changes you make in the property pane or source view should be properly reflected in the design view. Could we provide graphical support and/or better property pane/dialog support for some of the lesser MiGLayout features? Sure. That is a far cry from not supporting them
at all which is what you seem to imply. As to those lesser / esoteric features, we will take those requests on a case-by-case basis. We have several hundred users actively using MiGLayout right now, and have had very few requests for enhancement.
Now to address some of your specific complaints...
zartc wrote:The ability to specify docked components.
Here is some code taken almost verbatim from the MiGLayout docs...
- Code: Select all
contentPane.add(comp1);
contentPane.add(comp2);
contentPane.add(comp3, "wrap"); // Wrap to next row
contentPane.add(comp4);
contentPane.add(comp1N, "dock north");
contentPane.add(comp2W, "dock west");
contentPane.add(comp3S, "dock south");
contentPane.add(comp4E, "east"); // "dock" keyword are actually optional
...and here is how it renders in Swing Designer (with an added panel inset)...
You can specify the dock constraints in the source view (or in the property pane if you are using the latest Swing Designer build)...
zartc wrote:The ability to specify panel insets.
Easily done by specifying a
layoutConstraint in the property pane...
zartc wrote:The ability to specify grid gap (i.e. inter column and inter row gap).
You can do this by editing the
Specification in the Column or Row Properties dialog...
zartc wrote:The ability to split a cell in two or more (without introducing another column, using the 'slip n' component constraints).
This is easily done graphically in the design view...
zartc wrote:The ability to use platform independent unit value: 'related', 'unrelated', 'paragraph', 'indent', 'button'.
You can use any unit values that you want in the above Properties dialogs or anywhere you can directly edit the
Specification (Column, Row or Cell).
zartc wrote:The ability to specify components gap within there own cell.
The ability to specify component's min/pref/max size and grow/shrink/fill using component constraints (i.e. not column or row constraints).
The ability to specify meta-data tag on a component: 'ok', 'cancel', 'help', 'help2', 'yes', 'no', 'apply', 'next', 'back', 'finished', 'left', 'right'.
The ability to set the auto-wrap mode on the layout and add the 'wrap' and 'newline' constraints to individual component.
The ability to set debug mode, nogrid mode, visual-padding mode, cache mode, hide mode, flowy...
The ability to specify sizegroup/endgroup.
You can specify any arbitrary constraints that you want in the source view or in the property pane / property dialog. Swing Designer should properly parse and render all of them. Could we add better graphical and property support for some of these? Sure. Up until this point, no one has asked for any of these features to be handled in a nicer manner. The fact that the tool does allow you to specify them (and will render them properly if used) seems to have been sufficient for most users so far.
zartc wrote:The possibility to generate code that is not using the Absolute Cell Coordinate (i.e. cell x y).
While it is true that Swing Designer generates cell-based code, it will parse and render any style that you happen to use. The style of code it generates is purely aesthetic/cosmetic and should not affect the accuracy of the UI when executed. We could certainly add a preference to generate flow-based constraints in the future and allow you to toggle between them. While we have chosen (so far) to generate one specific style, we do parse and render all of them, so the tool should work with almost any hand-written or generated MiGLayout code that you run across (as shown above in the example taken from the MiGLayout docs).
zartc wrote:As you can see support for MigLayout is far from complete
As shown above, support for MiGLayout is far more complete than might be apparent at first glance.
zartc wrote:Can we expect a better coverage of MigLayout in next revisions ?
We are constantly enhancing the product on all fronts, and we give great consideration to feature requests made by our customers (as many folks in this forum can surely attest).
SwingDesignerPro-02229-xxxx