david@twg.com (David S. Herron) (09/15/90)
I would like to see two things:
-- Use of "lightweight processes" for some level of the widgetry. The
correct level is unclear to me at the moment.
This should make the code more linearly structured and thus
lessen the learning curve. My reasoning is based from the
following situation:
I have some lists which are maintained in my application. I have
control buttons which do Add, Delete and Edit operations. Sometimes
I want these operations to pop up some kind of dialog, then some
more stuff will be done. For instance, in Delete I'd pop up an
"Are you sure?" dialog, then if the user clicks on "YES, DAMMIT!"
the item would be deleted.
It would be nice if if I could write the callback for these operations
so that it would wait for an indication from the dialog. Instead
I have to set up the dialog so that it has a callback which would
do the rest of whatever it is I wanted to do.
-- Use of Prolog-ish "Horn (sp?) clauses" to evaluate callback lists.
Taking the above example I want to have a list-specific verify
callback check the data, then have a generic "add-to-scrolling-list"
callback which adds the item. The "generic" add/del/edit callbacks
specify the feel of how these lists work while various list-
specific callbacks coordinate the contents of each item.
A first step that would be quite useful would be to check the
return value from each callback as a Boolean. So long as the
callbacks return TRUE then execution proceeds, otherwise it stops.
In general it might be nice to implement some of the other PROLOG
things like "cuts" and so forth .. but I don't know enough of
that language to say what's necessary or not. In particular
the "keep trying til we succeed" idea doesn't seem useful(?)
in this case.
To implement this right now I have a data structure for the
scrolling-list in which the data for that list is kept. Part
of the data is a struct which looks like
struct verification {
int verify_flag;
#define VRFY_BAD 1
#define VRFY_GOOD 2
char *verify_text;
};
The first things done in the add/del/edit callback lists are to
1) verify that we're actually in the list
2) verify that various data items are `ok'
And callback's down the line check the verify_flag before proceeding,
and the last one in the line unsets the flag. (Or mebbe the first,
or mebbe both ends of the list?)
--
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!klute@heike.informatik.uni-dortmund.de (Rainer Klute) (09/18/90)
In article <7939@gollum.twg.com>, david@twg.com (David S. Herron) writes: |> I would like to see two things: |> |> -- Use of "lightweight processes" for some level of the widgetry. The |> correct level is unclear to me at the moment. N o , d o n ' t d o i t ! The lightweight process library is not only UNIX-specific, it is even SunOS-specific. Please consider those who do not program on a UNIX machine! Take me as an example: I am developing X software for BS2000 where you don't even have something like fork(). In general: Please write your applications as portable as possible! Put OS-specific things in separate modules. Design and document the interface clearly so that the system specific module can easyly be reprogrammed on another OS! -- Dipl.-Inform. Rainer Klute klute@unido.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ Tel.: +49 231 755-4663 D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386