Newsgroups: comp.windows.x
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: matt@saber.COM
Subject: Re:  Evaluating GUI tools (not quite a summary)
Message-ID: <9105171951.AA29530@rapier>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Date: 17 May 91 19:51:49 GMT
Lines: 98

Having at this point some accumulated some reasonable amount of experience
with the OI toolkit, let me offer a different viewpoint from the opinions
expressed here.

> = We are in just the same situation as you. I posted a message like this
> = a couple of weeks ago, and get very little response. My question was
> = about Object Interface Library / InterViews. My personal opinion is
> = that OI is not as good choice as IV. 

Whether OI or InterViews is a better choice depends on your goals.  If 
you're interested in producing OPEN LOOK and Motif compliant interfaces,
then OI is clearly the better choice, since Stanford's InterViews has its
own "look and feel".  If you're interested in a nifty researchy toolkit
with flyweight glyphs (which I personally think are a phenomenally good
idea), then InterViews might be more appropriate.

One subtle difference between OI and InterViews:  In InterViews, as in most
X11 user interface toolkits, the object hierarchy and the window hierarchy
are isomorphic.  In OI, that's not true.  The object hierarchy and the window
hierarchy are independent of each other.  

It's a little hard to explain in a few sentences why this is a good thing, 
but after programming in OI for a few months, I'm convinced that it's a 
fundamental advancement in toolkit design.  It allows you to design and 
implement an interface in terms of logical interface objects instead of 
thinking about window hierarchies, and provides tremendous flexibility
in building user interfaces.  It also allows more dynamic runtime behavior
than any other approach I've seen -- the ability to dynamically reparent 
any object to any other object at runtime and have all of the low-level
window details handled for you is just fantastic.

> = OI is now sold to AT&T and the
> = price is high, and it seems that very few people are using it. IV is a
> = free GUI from Standford University, it has a mailing list
> = (interviews@interviews.stanford.edu) and the source seems pretty good.

The lack of a binary distribution of OI is certainly a problem at the 
moment, but that's supposed to be getting fixed "soon".

> = At the moment I've not tried the OI, but I've read the manual pages. I
> = think that the OI is done in a 'me too' fashion, and it seems as a C
> = project hiding inside C++. 

Not at all -- OI is architecturally very different from most of the other
user interface toolkits available, InterViews included.

As for it being a "C project hiding inside C++", I'd be interested in
hearing what makes you think that.  There are two things that USED to make
me think that, until I understood why they were done this way:

	*  Objects are typically created using oi_create_xxx(...) 
	   instead of by using the ctor directly.  The reason turns
	   out to be that C++ doesn't provide any way for a ctor to
	   indicate failure.  That's the same reason InterViews has
	   the Valid member in classes whose ctors can fail -- whether
	   you prefer saying:

		Box *b = oi_create_box(...)
		if (b == NULL)
			Fail(...)

	   or

		Box *b = new Box(...)

		if (!b->Valid)
			Fail(...)

	   is largely a matter of personal choice.  OI lets you do it
	   the latter way, if that's what you prefer.  (The ctors are 
	   all there.  All the oi_create_xxx functions do is invoke the
	   ctor for the object, test for success, and clean up in case
	   of failure.)

	*  Member data is accessed via inline functions.  This turns
	   out to be a worthwhile C++ programming technique, especially
	   if during development you find yourself changing things from
	   data members into member functions (because they're harder to
	   compute than you thought). 

In fact, when you get into the sources, you find that OI makes extremely good
use of C++ as a language.  It would have to in order to provide the kind of
performance it does.  (I'm finding that apps created with the most recent
release of OI are generally slightly smaller than the corresponding OSF/Motif
or OLIT applications, while providing BOTH GUI styles and more flexibility in
behavior.)  It's also pretty easy to subclass almost any OI class you want.

> = One thing it seems to be a problem which is feared but not
> = handled is the problem with name clash. If you got the source you
> = always has the posibility to get out, OI hopes that no-one uses OI_ as
> = a prefix.

So far, I've not seen anyone suggest a bulletproof way to avoid name
clashes.  Picking a unique prefix for your public symbols and identifiers
seems to be the best you can do given the current state of the art in the
language design.


