Message-Id: <9301181856.AA13157@Athena.MIT.EDU>
To: pbailey@ceci.mit.edu
Cc: aybee@ceci.mit.edu, jud@ceci.mit.edu
Subject: "User Interface Classes"
Date: Mon, 18 Jan 93 13:56:01 -0500
From: Adam Feder <aybee@ceci.mit.edu>


hi phil ---

i just went through the version of your chapter that you gave me on Friday and once
again i have a few comments. (annoying, huh?)


my main criticism is that you have written a lot of class declarations, but have not
explained the model that the UI library will provide.  it allows the creation and
destruction of user interfaces. OK.  somehow, it lets you control when things should
and shouldnt be visible. OK. but how does a user of the UI library interact with it?
what callbacks are supported? what happens when the user presses a button? does the
library assume that it is providing the main loop and everything else you want done had
better be in callbacks before you enter the main loop?  if not, is the serviceUI loop
(no longer main loop) reentrant? how often would it have to be called? if it is the
main loop, does it provide timers and/or a method to schedule processing in slow UI
times? (i imagine that jud has some ideas on this topic already and he is about to
write about the am2 main loop, so maybe you could talk to him about it).

how do you handle errors? is it possible to register error handlers? or get error
events? (again, jud & i have discussed having a general error handling mechanism, but
have not figured one out yet (maybe based on exceptions), so any input would be helpful)
going back to the thread of control issues: what is synchronous? asynchronous? what
guarantees do you give users about timely event notification? (do you give any?)

in the section on Event Processing, you list a lot of types of messages, but what do
they mean in a system independent way? what if some types aren't available on a system?
does UIlib invent them? if not, can a user set a debugging switch to warn them when
they are using non-portable features?


:)
ab