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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.