🚀 go-pugleaf

> I would say supports Open Look, which may be forced to LOOK LIKE Motif

Unfortunately, you are basing your judgement on a demo you saw which had
roughly one man month invested in it, concentrating only on the look 
aspect.  The Motif implementation, when completed, will support both look
and feel.  As you observed, the scrollbars already do this.  I would differ
with you on your opinion of the difficulty of implementing keyboard
traversal.  I guess the proof will be in the pudding, but we have more than
one person here who would be willing to place some money on it.

> ...the basic window layout is different between Open Look and Motif

This is a real problem.  From our investigations so far, the primary 
difficulty is that the Motif style guide for applications appears to be
much more restrictive than OPENLOOK.  There are certain classes of
applications which cannot be written to conform to the Motif application
style guide without a very awkward interface.  For example, Motif specifies
that you use a menu bar, which may only have pulldown menus on it, and no
stand alone buttons, across the top of the main window.  What if the 
application has basically a single button in its top level window (This is
not a contrived example; it comes from a real application)?  To
conform to the style guide, you are forced to make a pulldown menu with a
single entry in it.

> file selection boxes, message boxes are different

This is not such a difficult problem, solvable by the toolkit in a manner
transparent to the application.  I'm guessing you are thinking of an interface
at too low a level, where you are only mapping elementary objects from one 
interface to the other, rather than treating "file selection" as an
object unto itself.

> OI does not (and can not) use X resource database.

Wrong.  OI can, and does, use the X resource database.  The current
implementation does not use the resource database for complete specifications
for all objects the way Xt does, however.  The reason it doesn't is
that the toolkit allows dynamic reparenting, which poses some problems
regarding resolving resource names.  We are working on solutions to that
problem and hope to have something in place by summer.
Existing applications get all sorts of things from the resource database.
The window manager gets its total configuration from resources.  The
debugger, mail and news readers, and other tools all get information
from the resource database.

> Neither it has anything like UIL. Thus any customizing must be provided
> for by the application code.

Wrong again.  It is a one line call to generate a complete object tree,
complete with hooks to callback routines.  We have shipped at least one
client program for months now which has no application code describing
any of its objects except those which it needs to create dynamically due
to changing conditions.  The client can easily be configured with a 
prototyper, and was built that way.

> OI is C++ only.

Yes.  All I can say is that anyone who would choose C over C++ after 
having used it has no concept of what object oriented programming really
is, or the benefits to be gained.  Yes, you can do object oriented
programming in C.  Unfortunately, C technology does not give you
all the benefits.  You cannot enforce data hiding.  You cannot enforce
strict type checking.  Even with the best of intentions, people will
make mistakes, and you will waste a lot of valuable engineering time chasing
down those bugs.

We chose not to implement a C interface (it is possible) deliberately, to
encourage our users to move to C++.  We have encountered no problems with
this that I am aware of.  Our os people, dedicated died in the wool C 
programmers, have managed to use C++ and OI with little effort.  Same
goes for graphics people, test people.

Having said all that, there is one reason I can think of to use C -- if
you are trying to write code to ship to the least common denominator
system, and you don't want to have to worry about C++ capabilities being
present or not.  But then, as someone said at the X conference: "If you
have a system which only supports 14 character file names, we consider
it broken, and the solution to that is to get a system which is not broken."
Maybe we should all code in FORTRAN or COBOL?  The same arguments were
used frequently years ago when C started gaining acceptance.

> I would like to see more native implementations of C++ with DEBUG support
> first.

Me too.  Although the tools available to us for C++ debugging are as good
as those for C, and are better than most.  We have full interactive debuggers
which understand C++ classes and demangle the member names.
--
Gary Aitken

Solbourne Computer Inc.    ARPA: garya@Solbourne.COM
Longmont, CO               UUCP: !{boulder,sun}!stan!garya