86 lines
4.2 KiB
Text
86 lines
4.2 KiB
Text
|
I just commited an implementation of GUI layout management, ported
|
||
|
|
over from my game project last year*. What this means is that you no
|
||
|
|
longer need to position your widgets manually in dialogs, and can
|
||
|
|
instead lay them out in tables and boxes like the pros do. :) I've
|
||
|
|
redone a few of the dialogs using the new scheme (I'm especially proud
|
||
|
|
of the autopilot dialog: http://plausible.org/andy/autopilot-new.png),
|
||
|
|
so you can see what the possibilities look like.
|
||
|
|
|
||
|
|
* FWIW, this is almost the last of my useful code from last spring.
|
||
|
|
Nasal and the Plib vertex splitting code are two other bits that
|
||
|
|
were useful in isolation. I also had a terrain engine and stencil
|
||
|
|
shadow implementation, but those weren't really production quality.
|
||
|
|
|
||
|
|
Basically, the implementation is a preprocessor on top of the existing
|
||
|
|
dialog properties, which sets x/y/width/height values based on
|
||
|
|
constraints. The <group> objects, including the top-level one which
|
||
|
|
represents the whole dialog, can now have a <layout> property, which
|
||
|
|
can be "hbox", "vbox", or "table".
|
||
|
|
|
||
|
|
The boxes simply lay out their children in order, either top-to-bottom
|
||
|
|
or left-to-right. The box name comes from Qt and Gtk, but this is
|
||
|
|
also the same thing that Java calls a "flow layout", or what the Tk
|
||
|
|
"packer" does. You can set "constraint" properties on the children,
|
||
|
|
to give the layout manager hints as to how to place the children. For
|
||
|
|
the boxes, these are:
|
||
|
|
|
||
|
|
equal: The box manager makes sure that all the widgets with this
|
||
|
|
constraint set to true get equal sizes big enough to fit the
|
||
|
|
largest one. This is very useful for button boxes to make
|
||
|
|
the "OK" and "Cancel" buttons match, for example.
|
||
|
|
stretch: Cells with "stretch" set to true get all the extra space,
|
||
|
|
if any, the box has to allocate. These are useful for
|
||
|
|
alignment purposes, especially when combined with <empty>
|
||
|
|
"widgets" (which are ignored by the dialog creation code,
|
||
|
|
but honored by the layout engine).
|
||
|
|
|
||
|
|
The table layout will be a little more familiar to anyone with HTML
|
||
|
|
experience. Children of tables get the following constraints:
|
||
|
|
|
||
|
|
row: The row number containing the upper left corner of the widget.
|
||
|
|
Table rows are zero-indexed.
|
||
|
|
col: The column number containing the upper left corner of the widget.
|
||
|
|
Table columns are zero-indexed.
|
||
|
|
rowspan: The number of rows spanned by the widget. Defaults to one.
|
||
|
|
colspan: The number of columns spanned by the widget. Defaults to
|
||
|
|
one.
|
||
|
|
|
||
|
|
Inside of each "cell", regardless of parent layout, there are some
|
||
|
|
constraints that are used to position the widget within the space
|
||
|
|
available:
|
||
|
|
|
||
|
|
halign: The horizontal alignment. Can be "left", "right",
|
||
|
|
"center", or "fill" (i.e. stretch to available space).
|
||
|
|
valign: The vertical alignment. Can be "top", "bottom",
|
||
|
|
"center", or "fill".
|
||
|
|
padding: The number of pixels to leave between the edge of the
|
||
|
|
cell and the widget.
|
||
|
|
pref-height:
|
||
|
|
pref-width: Overrides the default preferred size of the widget.
|
||
|
|
Note that this is the size of the widget only, not the
|
||
|
|
cell (which includes padding).
|
||
|
|
|
||
|
|
Also, the padding values for cells in a group can be set to a default
|
||
|
|
value with a <default-padding> property on the group widget.
|
||
|
|
|
||
|
|
Some will ask why didn't I implement this as part of Pui. The problem
|
||
|
|
is the pui just isn't set up for it. Not only is there no notion of
|
||
|
|
"preferred" size for a widget, there isn't anything remote like a
|
||
|
|
"constraint" system for attaching arbitrary values to widgets. With
|
||
|
|
the property system, I have that for free (the original code was
|
||
|
|
written to work with Nasal objects, btw). I can do the layout with
|
||
|
|
the properties and on the properties, and our existing dialog code
|
||
|
|
hardly needs to change at all.
|
||
|
|
|
||
|
|
Anyway, give it a try and see if I've broken anything. Also, note
|
||
|
|
that some of these changes *do* modify the visual appearance of the
|
||
|
|
GUI. I think it looks better, but opinions will no doubt vary. Shout
|
||
|
|
if you hate it.
|
||
|
|
|
||
|
|
And finally, the text alignment doesn't quite look right with current
|
||
|
|
plib due to some minor rendering bugs. Bug Steve to apply the patch I
|
||
|
|
submitted a week or so ago. :)
|
||
|
|
|
||
|
|
Andy
|
||
|
|
|