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.