From: twbrown@PE-Nelson.COM (Tom W. Brown)
Newsgroups: comp.windows.open-look,comp.windows.x.motif
Subject: SUMMARY: Request for feedback on OI [LONG]
Keywords: OI, OPENLOOK, OLIT, Motif, C++
Date: 8 Apr 92 17:26:32 GMT
Followup-To: comp.windows.open-look
Organization: PE-Nelson

Hello again,

I received a fairly good response on the request for feedback on the OI
toolkit so here is a summary.  First, I'll provide a brief summary (in 
a probably vain attempt to get it on one page) and follow it with the
original questions I asked and the various responses:

Toolkit compliance, completeness and the X resource database:
   Very good on compliance and completeness (one negative response) and
   better use of the resource mechanism than either OLIT or Motif.

Handling objects like the pushpin that don't exist in both toolkits:
   Objects have been created where necessary for the appropriate model.
   The pushpin is available for Motif model dialog boxes, but not for
   Motif menus.

Layout in OI vs. the XmForm widget:
   OI has layout but it is not the same as the form widget, a future rev
   will (may) have a form-type object.  Constraint style layout can be 
   done now by subclassing.

Complexity of the class hierarchy:
   (from the OI class tree provided by a response from Solbourne) There are 
   47 classes, 13 of which are abstract base classes.  The tree has 7 levels 
   of inheritance at its deepest.  The tree appears to be monolithic (every
   class inherits from a single root ancestor) and does not appear to use 
   multiple inheritance.

Portability:
   Currently runs on SPARC.  Will eventually run on IBM RS/6000 and others.
   A VMS port has apparently been done by someone already.

Licensing, AT&T vs. Solbourne:
   The contract with AT&T expired and was not renewed.  Solbource has full
   rights to the product and will license distribution rights to others.

Documentation and Support:
   Appear to be quite good, "better than average for the Unix world."  A
   1000 page reference manual, tutorial, and man pages.  Support handled
   by Solbourne.


Some issues that came up not directly related to any of my questions but
are very interesting are:

   -  OI comes with an interface builder, UIB, which apparently "beats
      the pants off Guide."

   -  OI has a built-in hypertext help object for both OPENLOOK and
      Motif models.

===============================================================================
> How "complete" is the Motif and OpenLook compliance?  I would expect
> interfaces developed in OI to _look_ exactly like their OLIT or Motif
> counterparts, but do they fully support the X resource database, key
> and button bindings via a translation table, etc.?

   * Certainly uses resources as per X.  Look and feel seem(!) to be well
     done for OpenLook but can't speak for Motif.

   * We do a good job of emulating the look and feel of Motif and OPEN
     LOOK.  We fully support the X resource database, key and button
     bindings (any X event) via translations, have accelerators and
     mnemonics (the latter only in Motif for the most current release, both
     in the future), etc

   * OI makes much more extensive use of resources than any competing
     toolkit; I think you are in good shape here.

   * It's pretty complete.  There are a few things missing (paned windows
     from the Motif model and splittable text views in OpenLook, but by
     and large most things are there and work well.

     OI fully supports the X11 resource database.  In fact, the OI toolkit
     makes better use of the resource database than many other toolkits.

     I've actually found more problems with the "look" than with the feel;
     [...] Most of these have to do with things like spacing between
     objects [...] Purists may gripe a bit, but most reasonable users
     probably won't have a problem.

   * They don't look EXACTLY like their OLIT and Motif counterparts in all
     cases.  In general, it's a pretty good match.  OI supports the X 
     resource database bettern than either OLIT or Motif.

   * Unfortunately, I can only give you some second-hand information from
     someone who had considered using OI: apparently, the claim for support
     of both Motif and OLIT was not fulfilled.  A least common denominator
     approach and non-identical graphical conformance to the standard
     widget look resulted in interfasces that looked equally bad in either
     style.

   * OpenLook compliance appears better than Motif.  The objects don't
     understand Xm or OLIT resource specs, though.


> How are objects like the pushpin handled that exist only in OLIT but
> not in Motif?

   * For pushpinned menus, the pin isn't present in Motif.  For dialog boxes,
     you can enable the pushpin in Motif via a resource.  We implemented
     OPEN LOOK counterparts for all the funky Motif dialog boxes.

   * Pushpins are part of the window manager, so it depends on the window
     manager that you choose.

   * Depends on the kind of object.  For generic components like the gauge,
     OI simply implements a gauge object in the Motif model.  Pushpins
     are a special case.

   * There are several objects of interest:
      - Pushpins: If you ask for one and the model is OPENLOOK or OPENLOOK3D,
        you get one.  If the model is Motif, you normally get nothing.  This
        does not affect the semantics of the program, however.

      - Help: OPENLOOK defines a help dialog box.  In addition, OI provides
        a built in hypertext help system [...] When running in Motif, a
        motif style equivalent is provided.

      - Gauge: A Motif style equivalent is provided.

      - Dialog Boxes: OPENLOOK style equivalents have been provided for
        the 6 variants (plus prompt selection, file selection, and
        command dialog) of message dialogs.

> We make heavy use of the XmForm widget for layout, is there a
> corresponding constraint object in the OI hierarchy and does it function
> in both the Motif and OpenLook modes?

   * There is a similar class to Form but the constraint specification
     approach is different.  Resizing seems much more intuitive and, above
     all, less effort than with OLIT/Guide.

   * Layout works no matter what model you are running under.  Layout is
     different than constraint objects. Layout is like a constraint object,
     except that it works for all objects in the hierarchy.

   * There's support for automatic layout in OI, and there are three standard
     layout methods currently implemented (row, column, and OL-style row
     aligned by item label).  There is nothing as rich (or complicated) as
     the Motif form widget provided in OI.  OI layout methods are classes, so
     integrating a new one [constraint based] should be easy.

   * The current version does not support a form layout.  A future version
     will.  The current version does provide a callback when an object is
     resized, so you could manually adjust object locations in the callback.

> Qualitatively, how "complex" would you say the OI class hierarchy is?
> Not to knock InterViews (and I _don't_ want to start an OI/Interviews
> war) but I have to say the class hierarchy for that toolkit is, or
> at least appears to the uninitiated, incredibly complex.

   * Lots of classes, but logical use of inheritance so it is easy to
     understand.

   * We have lots of objects that are very general, but you'd have to take
     a closer look at the documentation to get an answer to that question.

   * Not as complex as Interviews.  It's still a C++ toolkit, but is
     based much more on specialization-by-providing-callbacks than on 
     specialization-by-subclassing (although the latter can be done in
     OI, of course).

   * It's fairly deep, but that's a byproduct of good thinking about
     hierarchies; it's not Xm, where four or five widgets are packed into
     one class.

> What about portability issues?  We are currently developing for
> Sparc workstations (Sun) but anticipate the need to support other UNIX/X
> Windows systems as well as VMS/DEC Windows systems.

   * We run on SPARC systems.  Other people have ported OI to HP boxes,
     IBM RS/6000, DECstations, and even VMS.  OI is built on top of XLib.

   * CenterLine is porting to lots of platforms.

   * OI is currently shipping for SPARC only.  We are currently porting to
     the IBM RS/6000.  We plan ports for DEC and HP.  A previous version
     of the library has been ported to VMS by a beta site.

   * Source is available from Solbourne.

> It was my impression that an earlier version of OI was being exclusively
> handled by AT&T, but that Solbourne has now taken this back.  Is this,
> indeed, the case?

   * We [Solbourne] are selling it now.  The contract with AT&T ran out and
     was not renewed.

   * Solbourne has authorized a few resellers, including Qualix and
     CenterLine.

   * Solbourne is licensing distribution rights for OI and UIB to other
     companies.  We'll [CenterLine] be selling both OI and a version of
     UIB.  I think Qualix and ParcPlace are also going to be distributing
     OI.

> What, qualitative, opinions do you have regarding product documentation
> and support?  Is the documentation simply hardcopied man pages or is
> there more (e.g. programmer's guide and tutorials)?

   * There is a 1000 page book describing everything you need to know to
     use OI.  Support is done right now by the same people that wrote the
     toolkit or one of our [Solbourne] applications.

   * All are far above average for the Unix world.  There is an extensive
     tutorial and user manual.  There is also a good email list for it.
     We [Qualix] support it on Sparc platforms.

   * There is a 39 chapter OI reference manual, which is really quite
     good.  CenterLine may end up supplying additional documentation,
     tutorials, etc.

   * I haven't purchased it yet; but I should say that I'm very impressed
     with the OI developers I know, and I trust them to have done a
     Good Job.
==============================================================================

Many thanks to everyone who responded to the posting!  We will definitely
be obtaining an evaluation copy based on the positive feedback.

-- Tom Brown
   PE Nelson Systems
   twbrown@pe-nelson.com