Xref: utzoo comp.windows.misc:1610 comp.windows.x:26983
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!twg.com!david
From: david@twg.com (David S. Herron)
Newsgroups: comp.windows.misc,comp.windows.x
Subject: Maybe R5 wishes, or a "better" way to construct X, or something
Message-ID: <7939@gollum.twg.com>
Date: 14 Sep 90 19:05:16 GMT
Reply-To: david@twg.com (David S. Herron)
Followup-To: comp.windows.misc
Organization: The Wollongong Group, Palo Alto, CA
Lines: 62

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!