Re: Dynamic ... something

Wolfgang Thaller wrote:

> So allow me to try to summarize the discussion about dynamic layout:
> 
> We'll have one or more of the following (correct me if I left something 
> out, or if I'm misrepresenting something):

For Xt (Athena, Motif), you have a choice of:

1. Programmatic creation of widgets with programmatic specification of
layout attributes.

2. Programmatic creation of widgets with layout attributes taken from
X resources.

For Motif, you have some additional choices:

3. Creation of widgets from UID (compiled UIL) files, with layout
attributes specified in the UIL/UID files.

4. Creation of widgets from UID (compiled UIL) files, with layout
attributes taken from X resources.

In all four cases, the set of available layout attributes depends upon
the widget's parent (container). Some (e.g. XmRowColumn) have minimal
or no layout attributes; others (e.g. XmForm) have extensive layout
attributes. For XmForm, absolute positioning is just one possible
option (effectively, the top/left attachments are to the edges of the
parent, with offsets specified in pixels).

> Something like:
> nib <- loadAppleNibFile_MAC "foo.nib" -- a nib file is a document 
> created by Apple's Interface Builder and contains one or more dialogs
> dialog <- createDialogFromNib_MAC nib "MyDialog"
> If "MyDialog" doesn't refer to a dialog in the file, a runtime error 
> occurs...

For UIL, you also have to provide definitions for any attribute values
which can't be specified inside a UIL file (e.g. pointers, callbacks). 
Basically, the UIL file uses symbolic names, and you provide a list of
name/value pairs to map the names to specific values when loading the
file.

> What about making layout management a feature of a containter widget?
> When adding widgets to a FixedLayoutContainer, you'd have to specify 
> the coordinates, when adding widgets to a GridLayoutContainer, you'd 
> specify row & column, etc.
> We could start with just a FixedLayoutContainer (that's easy), and then 
> we can go on and add "more intelligent" layout mechanisms.

Specifying fixed coordinates is likely to violate native look-and-feel
(you have no idea what the default font is), and will break down if
the application is customised (e.g. changing labels).

Allowing fixed-coordinate layouts is an open invitation for people to
write code which only works correctly on their system; they will just
tweak the numbers until it looks correct with their preferences.

> Another, similar approach would be to make the "layout manager" an 
> _attribute_ of a container widget (as is done in Java's AWT, if I 
> remember correctly). Don't know if that has any advantages for our 
> situation.

Java's AWT is a great way to write programs which are instantly
recognisable as "Java AWT" programs (i.e. instantly distinguishable
from "native" programs).

If you want native l&f, you have to redo the layout for each platform. 
If you try to impose a portable solution, you'll end up with something
that doesn't have native l&f on anything. Even if all of the common
platforms provided exactly the same layout interface, unless they also
had identical style guides, you would need to re-implement the layout
for each platform.

The easiest way to get both portability and native l&f is to use
external interface definitions. The interface definitions themselves
aren't remotely portable, but at least it keeps the non-portability
out of the actual code.

Of course, people may ultimately decide that native l&f is just too
much work, and abandon it. It's certainly an option. But, if native
l&f is abandoned, it should be a conscious decision, rather than a
accidental consequence of not realising what's involved until too
late. Also, it makes it less likely that the end result will actually
be the one-and-only UI library; if Haskell is around long enough,
eventually someone may want native l&f badly enough to implement a
library which provides it.

-- 
Glynn Clements <[email protected]>