From: vin@netcom.com (Vin Locke)
Subject: mechanism vs policy (was: Ranting about faults in NeXTstep)
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 12 Oct 1992 02:19:24 GMT

In article <80932@ut-emx.uucp> alex@fiskville.mc.utexas.edu writes:
>It would appear that you have come upon what might be called a bug or,  
>rather, a feature that was overlooked for implementation. Rather than  
>ranting about it here (where it will do you very little good) why not  
>email someone at NeXT and politely mention to them that you feel this is  
>an important aspect of the operating system that was left out. I am sure  
>that your comments... your positive feedback... will have some value to  
>NeXT and your suggestions may be included in a future system revision.  
>NeXT claims to be very serious about being a flexible environment and this  
>feature sounds like it could be useful so perhaps they will listen  
>(although I wouldn't call them idiots to their faces). 
>
>
>Matthew Dillon writes
>>  Somebody over there decided not only to force windows to the front when
>>  someone makes them the key window, but also to simply NOT provide *ANY*
>>  method to make it the key window without bringing it to the front. What
>>  idiot decided that ?  I don't mind the *default* being to bring it to
>>  the front, that makes sense, but to not even provide a method to
>>  activate a window without bringing it to the front is stupid.
[stuff deleted]


When learning Xwindows application programming, one learns that the original
philosophy of the X design is/was "mechanism, not policy" -- I've seen this
phrase used in a number of places (about as numerous as the times George Bush
used the phrase "tax and spend" in the debate)(well, almost).  If one were to
get down to the nitty-gritty and program exclusively in Xlib, one could
probably come up with some fairly unique interface windows.  The hit here is
development time, but you'd have the utmost in window-design freedom, 
especially since the release of R5, where none-rectangular windows are 
possible (though I've yet to see one of these -- I'm still in R4 when I X).
When one goes to widget sets, well, in a way, policy starts to creep in:
this is what a radio button looks like, this is what a menu looks like,
etc.  Of course, you still have the option of rolling your own widgets, 
but the purpose of the toolkits is to prevent you from having to.
	It seems that NeXT, in the name of interface consistency among 
applications, has decided to adopt a policy as well as mechanism.  This can
be seen as a Good Thing(tm) and usually is.  Policy usually involves 
enforcement, and in the NeXTstep environment, this enforcement takes the
shape in a lack of freedom -- for instance, the inabilty to have a window 
become the key window without order front in the workspace.
	I would think this inabilty is not oversight, especially since it is
still this way in 3.0.  The engineers/designers at NeXT are by no means
X-illerate -- I know this for fact because one of my Dev Camp instructors
used to work with X.  My guess is that we don't have a Preference for this
ability because consistency is a desired goal (if this is settable, would
someone please post the way to acheive it?); for instance, on my
(name of other Unix workstation censored for the faint of heart) workstation
at my job, I have the thumbscrew on the left and for a window to become key, 
one must click the mouse in it -- all my co-workers have the thumbscrew on
the left and the window with the pointer becomes active on entry (just like 
the "policy" of you-know-what).  People
get frustrated when they have to use my machine, but oh well . . . ;^)
Anyway, maybe this is the sort of thing NeXTstep is trying to avoid.

(just for the record, I, too, would like this ability to make a window key 
without bringing it to the front).


-- 
					--vin

vin@netcom.com

"...you think YOU know fear -- I've seen them naked!"
				--L. Simpson
Newsgroups: comp.sys.next.advocacy