Xref: utzoo comp.windows.x:33177 comp.windows.x.motif:2012 comp.windows.open-look:681
Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!msi.umn.edu!cs.umn.edu!brsmith
From: brsmith@cs.umn.edu (Brian R. Smith)
Newsgroups: comp.windows.x,comp.windows.x.motif,comp.windows.open-look
Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel
Keywords: toolkit, Open Look, OSF/Motif, GUI
Message-ID: <1991Feb20.170617.15372@cs.umn.edu>
Date: 20 Feb 91 17:06:17 GMT
References: <1322@ixos.de> <1057@attc.UUCP> <1991Feb19.210822.26826@visix.com>
Organization: University of Minnesota, Minneapolis, CSci dept.
Lines: 67

In <1991Feb19.210822.26826@visix.com> amanda@visix.com (Amanda Walker) writes:

>In article <1057@attc.UUCP> marbru@auto-trol.UUCP (Martin Brunecky) writes:
>>   Solbourne OI is probably as close as you can ever get. I think
>>   they did a very good job implementing UI *components* which can
>>   act "both ways". 

>OI looks deeply cool, but even it has some drawbacks.  You need C++,
>for one.  Some of us are not yet convinced that C++ is The One True
>Way :).

Ack!  An unbeliever!  :-)

I'm not yet convinced that OI is the One True Schizophrenic Toolkit,
either.  From what little I've seen, it didn't look nearly as elegant
as InterViews.  (InterViews == a different toolkit, also in C++)

I.E. In an example of how to create a scrollbar, they called a routine
named "oi_create_scrollbar()" or such.  This may make sense in C, but
C++ has constructors.  In InterViews, you'd just declare it, like;
  HScroller Foo(scrollme);  // scrollme is the object to be scrolled

or create a new one;
  new HScroller *Foo = HScroller(scrollme);

I don't understand why they didn't use constructors, and my first
guess is that the implementor wasn't completely comfortable with C++.

Also, OI appeared to be dual-look only on an object-by-object basis -
you would still have to adjust for different interface styles in your
application code.

>[...] Low-level details of user interface policy should not be
>reflected in the "toolkit" API; if they need to be, it means that API
>is not sufficiently expressive, or high enough level.  The
>application should specify what it wants to do, not how to do it.

I don't think it's going to be possible to express the functionality
of an "application" generically and yet with enough detail that it
could be expressed meaningfully in multiple different look-and-feels.

The only way I can think of to do something like it, and do it well,
would be to implement the application the same way as the base user
interface objects - so that IT also understands each of the possible
look-and-feels necessary.

I.E. Say you were making a simple "edit" window that needed to be
scrollable.  It consists of a vertical string of data and a scroll
bar, pasted together in some magic way.  GUI X *requires* that
scrollbars be on the right, while GUI Y lets the user decide.  The
edit window must understand both of these conventions, and decide
between them.  (Notice I didn't say a text editing window, which
most toolkits already have.  This window is filled with some kind
of data that no toolkit developer would ever code for.  Really.)

Trying to make a toolkit that understands application-by-application
foibles is hard.  Extending the toolkit to include the objects YOUR
application requires makes much more sense to me.  So you need a
toolkit that is easily extensible.  Yay for C++ and subclassing...

>Disclaimer: I get paid to change this situation :).

And I'm heavily biased towards C++ and InterViews, but for All The
Right Reasons, I think.  :-)
--
Brian              | <This space intentionally left almost blank.>
brsmith@cs.umn.edu |