🚀 go-pugleaf

>From: mike@bach.cs.byu.edu (Mike Burbidge)
>Subject: Toolkit decisions (was: XView v. other toolkits, advice wanted)
>
>	XView is not very object-oriented. It is simply a static set of objects
>for building user interfaces. It does not support inheritance. If there is not
>an object in the toolkit that does what you want, you build one from scratch.
>You can put XView objects together in a statically prescribed manner, but very
>often in real world applications that is not what you want to do.
>
>Mike Burbidge.
>mike@cs.byu.edu

Mike, the concept of a toolkit being object-oriented is not strictly
limited to Smalltalk-style environments.  XView is an object-oriented
system with static subclassing.  This simply means that the heirarchy
of classes need to be defined at compile time (the same is true of the X
Intrinsics).  Additionally, all XView objects are "opaque" and do not
expose the internal representation/implementation of the objects.
XView objects have their contents/values retrieved/set using attributes
(used as "messages") with generic functions [xv_get() and xv_set()]
while other generic functions are used to instantiate/destroy all
objects [xv_create() and xv_destroy()].

Your comments about creating new objects are misleading.  Existing 
objects are easily changed within the scope of their attributes.  
Features/changes outside this scope do require building your own,
but since XView source is widely available and freely distributed,
having to "build one from scratch" is more clearly described as
"clone one from existing code".  It is also our stated policy to
"take back" such additions into mainline XView source (where the
this is reasonable for the general user community and the programmer
is amicable with his/her changes).

Tom Jacobs				ARPA: tomj@eng.sun.COM
Window Systems Group			UUCP: sun!tomj
Sun Microsystems, Inc.