🚀 go-pugleaf

In article <1991Jun21.183405.26015@colorado.edu> thompsog@spot.Colorado.EDU (THOMPSON GEOFF) writes:
>In article <1991Jun19.173316.18566@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes:
>>In article <1991Jun18.205101.28425@colorado.edu> thompsog@spot.Colorado.EDU (THOMPSON GEOFF) writes:
>>>by accessing the native window sytem components of XVT objects. Hence, the
>>>term "Extensible." In general, the full capabilties of the native window
>>>system are available in non-portable ways, including handling all native
>>>system events.
>>However, manager-type widgets like forms, rowcolums, tables... are not
>>accessable, unless quite a bit has changed since I last looked at XVT.
>>In my mind this toss out one of the best features of Xt.

As I say many many many many times -- a reasonable toolkit for
building these sort of applications should provide facilities
like the form & rowcolumn & table widgets.  The fact that XVT does
not is one of its GREAT LACKS.

>In general, if you want to do something non-portably in XVT, you should
>be able to do most anything the underlying toolkit, window system, and
>operating system allow.

Yes.. but why should this be non-portable?  That is, why should
these features be lacking?

Regardless my impression is that bypassing XVT to get to the underlying
windowing system is exceedingly hard.  Maybe not..  For instance
the CURL compiler produces UIL, one could edit that and make it
use whatever widgets you wanted...


In addition to Kee's objections I have some critisms of XVT.  Note
that I am first & foremost exceedingly uninterested in PC & MacIntosh
portability, I use XVT because the people who pay me want that
portability.  My use for the MacIntosh in my office is target
practice with rubber bands ;-).  I have worked in Motif for 1.5
years, and also have a half-completed implementation of an
XVT-compatible toolkit.

In no particular order ...

The API is very inconsistent and rather silly in places.  For
instance there are a couple of XVT objects which keep lines
of text.  They have an almost useful data structure, the SLIST
(Which seems to be "struct SLIST {char *s; long data; struct SLIST *next;}")
but which is used for only one of these objects.  Another facet
is in specifying location/size of a rectangle (for locating an
object on the screen).  In some instances you specify {x,y,width,height}
and in others it is {top,left,bottom,right}.


programmer gets involved at too low a level -- There are a couple
of aspects to this.  For instance, the way you design a window
is to drag out some graph paper and measure out x&y coordinates.
For instance, the program gets told of some very uninteresting events.
Like if the mouse is clicked anywhere with one of my windows
an event is generated.. I cannot imagine wanting to be interested
in that, unless the window had a "drawing area" in it.  Instead
I, as a programmer, am only interested in whether a button was
pushed, or an item in a listbox was selected, or whatever.  There
should be a way to tell XVT to not generate those events.


the events are backwards from what they should be -- The structure 
of programs are much like how I understand that Microsoft WINDOWS
programs are structured.  That is.. each window has a single routine
into which ALL the events are funneled.  This is every single last
one including mouse location reports.  (Actually, XVT doesn't
report mouse locations unless the mouse is dragging something..
it is WINDOWS which does this).  Then events which the application
programmer is uninterested in are passed into a standard routine
in the toolkit.  This is very different from how Xt programmers,
like myself, expect programs to be organized.  Instead we only
get events of interest, and instead of being delivered to one
routine which holds the world they are delivered to their own
individual routines.

A reason this is important has to do with common-courtesy
in a multi-tasking system.  WINDOWS can get away with throwing
away CPU power on notifying application programs of events
they aren't going to be interested in because it's a single
tasking computer.  X, on the other hand, has to not only
share the system but also the ethernet cable with other
processes.  Therefore delivering uninteresting events should
be highly frowned upon.


it really is the least common denominator -- People have tried
to claim otherwise.  But they are wrong.  You have available
a very small set of objects (text entry & display, buttons,
listboxes, scrollbars and drawing primitives) and no way to
extend these in useful/interesting/object-oriented ways.  Weeell,
they do have a C++ toolkit/front-end, dunno how useful it is
but the blurb didn't sound too promising.  Like Kee said above,
it does not provide any interesting facilities...


	David

-- 
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<-
<-
<- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future