Hello All, I've been silently listening to the recent threads. I feel like some of these conversations are going back to issues discussed a month or two ago. So here is a concrete proposal. Yay or nay. I suggest merging this with the standard and then changing it with other proposals. This seems to be an effective way of getting things done. 1.) class Widget where -- Some operations on widgets such as getHeight getWidth (the units of these are not yet specified) 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). For read only variables that do not fit into an obvious class will have their own class ( class HasGetFoobar where ... ) 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() The doOn<A> function returns a function which can be used to disconnect the signal. 4.) A widget <A> with (a1, a2, ...) write only variables is created with: mk<A> :: a1 -> a2 -> ... -> [Prop <A>] -> IO <A> 5.) Issues to push back for discussion for a future CGA release: a.) Resource files. b.) Internationalization. c.) GUI designer. 6.) Position, width, and size will be able to be programmed a.) Dynamically, and b.) Concretely This proposal maintains the original goals of being typesafe and fully dynamic. As I said above, lets ratify this (yay or nay) and then consider proposals for changes and additions. Sincerely, David J. Sankel
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.
participants (2)
-
Axel Simon -
David Sankel