Community
Participate
Working Groups
Created attachment 81680 [details] FormDataBuilder FormLayouts are one of the most powerful layouts available in SWT, but it is also one of the most complex, and for that reason it is used far less than it could be. There are a number of difficulties with this layout that novice users often fail to overcome: * FormAttachments are an extra class to try to understand, and their api is often difficult to relate to the particular attachment point on which it is being used. For instance, when creating a FormAttachment for the left attachment point it only makes sense to use SWT.LEFT, SWT.RIGHT, or SWT.CENTER for the alignment, but the API specifies that SWT.TOP and SWT.BOTTOM can be used as well. This is due to the fact that nothing tells the attachment where it will be used. * "Offsets" are used in the layout rather than "padding", causing the consumer to have issues related to having the wrong sign on the offset. * It is often necessary to calculate the preferred size of a control in order to determine the correct offsets to use. This is most common when trying to center a control in a composite for example. In order to make this layout easier to learn and use, I request that we add a FormDataBuilder to 3.4. This would use the builder pattern to facilitate the creation of the FormData. I have created a version of this as a jumping-off point for discussion which solves the three issues outlined above, as well as some others. It intentionally differs from the way the GridDataFactory works due to the differences in the way the two different types of layout data are used. Whereas a GridData may be very similar across multiple controls, each FormData will be highly unique, and so a Factory makes less sense. I also have a version that follows GridDataFactory as closely as possible if anyone is interested in seeing it, but I believe the builder to be superior.
Any comments at all on this? Suggestions for improvement? I'd love to see something like this in a future release to help save us all from inappropriate uses of the GridLayout, as wonderful as it is. :)
I remember form from the motif days and how mind-bending yet powerful it could be! I haven't looked at your patch in any detail, but I think one thing that might help is to see a snippet of some dialog that is currently using grid layout that benefits from switching over...ie, how it makes either the layout itself or the readability of the code better. One issue is that the dialog framework assumes a grid layout so often the most tricky layouts (dialogs, wizard and dialog pages, etc.) have to use a grid layout, at least at the dialog area level, and using this would mean nesting an extra composite with a form layout...
Rather than converting a GridLayout to use FormDataBuilder + formlayout, I would be interested in seeing how this class would affect an existing dialog that uses FormLayout. The more complicated the layout, the better. I don't think the benefits of this class would really shine through in a gridlayout-to-formlayout conversion, since grid layout code tends to be a lot simpler than form layout code. My gut feeling is that this class should probably mimic the code style of GridDataFactory, GridLayoutFactory, RowDataFactory, and RowLayoutFactory as closely as possible. Even though users will rarely (or never) create multiple identical FormData objects, the factory code style will be familiar. That said, however: it's not immediately clear to me how one would create the FormAttachments with a factory-style pattern so the builder approach might still be the best. Could you attach the other version of your patch so we can see how you did things and compare?
(In reply to comment #3) > Could you attach the other version of your patch so we can see how you did > things and compare? Actually, I wrote that a couple years and one job ago now, and I don't have that code any longer. Sorry!
Created attachment 139283 [details] Snippet of original form layout Here is some "move box" code that has come up a few times for me, and a basic implementation using FormLayout. Note that if a GridLayout were used, there would be issues when long items were added to the lists, which is why FormLayout was chosen here.
Created attachment 139284 [details] Snippet using FormLayoutBuilder Updated to use the FormDataBuilder, the code is much less error prone, reads a lot easier, the layout code is one eighth the size, and took me about a quarter of the time to write (and I wrote it first, so I had it to copy from for the other one).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
