Re: Dynamic ... something
Wolfgang Thaller <[email protected]>
| Newsgroups | gmane.comp.lang.haskell.gui |
|---|---|
| Message-ID | <[email protected]> |
Axel Simon wrote: > On Sat, Apr 12, 2003 at 06:54:13PM +0200, Wolfgang Thaller wrote: >> None of the approaches need to be mutually exclusive, though: >> >> 1) Explicit placement >> (should not be used directly except in some strange case that I just >> can't think of) >> 2) Platform-specific interface definition files >> 3) Dynamic layout >> > I don't like the idea of separating explicit placement and dynamic > layout. Explicit placement is, of course, just one very simple layout algorithm. I was not talking about separating it from the rest. * Explicit placement is a layout algorithm, just like a GridBagLayout * It is available on all platforms * It is easy to implement on all platforms * It is the only thing that is available on some platforms, so on those platforms, we'll have to implement the other algorithms on top of that * Because it's easy to implement on all platforms, it will be useful in the early testing phases * Because we need it as a base to implement better algorithms on Windows & Aqua, we might as well have a convenient interface to it * It's use for laying out dialogs should, of course, be discouraged, for the sake of cross-platform compatibility. * I'm sure that there are some strange situations where it is necessary, and if the application can query things like minimum and recommended sizes, font sizes are no problem > If > we provide a set of simple combinators, these combinators can calculate > fixed positions for Windows and Aqua but use the widget containers > which > allow resizing on Gtk and Motif. Resizing is a different issue. Mac OS Cocoa only has explicit placement, but does automatic resizing. Also, consider a document window: You'd need to place some content-area widget (e.g. a text widget), and two scrollbar widgets. Of course we need resizing, even for windows. As I said, there is no mutual exclusion. We should probably have good layout combinators, but we should also have an "explicit placement" combinator because I need it as a base to implement the other combinators on on Mac OS; also, it's a useful thing to have in some situations. > Using combinators doesn't go along > with absolute pixel positions anyway as far as I can tell. I don't get that... what do you mean by this? > I therefore opose to taking "explicit placement" as a starting > point. I was suggesting that we should start with explicit placement because it is by far the simplest mechanism; we can then already implement and test other parts of the CGA, before all the dynamic layout mechanisms are implemented on Mac OS and Windows. Cheers, Wolfgang