Re: Recent threads

On Tue, Apr 15, 2003 at 05:09:32PM -0700, David Sankel wrote:
> 1.)  class Widget where
>     -- Some operations on widgets such as getHeight
> getWidth (the units of these are not yet specified)
 Nay :-) I don't like widget classes to contain funcitons
(see earlier email).

> 2.)  Widgets have several types of variables
>   a) r/w variables are handled by attributes
>   b) write only variables are passed to the
> constructor before the attribute list.
>   c) read only variables are handled by functions such
> as (getWidth :: Widget a => a -> Int).
Yes, agreed.


>  For read only
> variables that do not fit into an obvious class will
> have their own class ( class HasGetFoobar where ... )
 I don't like attributes lumped into classes. Same thing
as above.
 
> 3.) callbacks are not variables.  Signal is a more
> appropriate descriptor than variable.  For a given
> signal <A> with parameters (a1, a2, ... ) :
> 
>   class EmitsSignal<A> a where
>     doOn<A> :: a -> ( a1 -> a2 -> . . . -> IO() ) ->
> IO()
 If they are not in classes, then: yes. I think we should
say "attributes" when we talk about the properties we set
in the list to the constructor.

>   The doOn<A> function returns a function which can be
> used to disconnect the signal.
Yes.

> 4.) A widget <A> with (a1, a2, ...) write only
> variables is created with:
>    mk<A> :: a1 -> a2 -> ... -> [Prop <A>] -> IO <A>
Yes.

> 5.) Issues to push back for discussion for a future
> CGA release:
>    a.) Resource files.
>    b.) Internationalization.
>    c.) GUI designer.
We have to consider a) before we talk about layout issues.
 
> 6.) Position, width, and size will be able to be
> programmed
>    a.) Dynamically, and
>    b.) Concretely
 If the position-in-concrete-units backends (Window and Apple) insist 
that there are situations where the side-by-side and above and below 
combinators are not cool enough to lay out Dialogs/Windows, then I will 
agree to b.).

Axel.