Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!stan!garya
From: garya@Solbourne.COM (Gary Aitken)
Newsgroups: comp.windows.x
Subject: Re: (OI) Toolkit for Open Look *and* OSF/Motif Look and Feel
Message-ID: <1991Feb26.234801.22605@Solbourne.COM>
Date: 26 Feb 91 23:48:01 GMT
Organization: Solbourne Computer, Inc.
Lines: 106

> Presumbably you didn't put any buttons in the menubar, since
> you aren't supposed to do that in Motif.

But you also aren't required to have a menubar.

> Do you have a Help pulldown in the menubar?

You get it automatically in the Motif model.
You supply the pulldown.

> Do the entries have the same wording in Motif as in Open Look?
> How about the menubar, is the order of pulldowns (when applicable)
> File, Edit, View, Options, Help?  How about the contents of the menus?
> Are the entries in Motif order with the Motif specified names?  In the Edit
> menu (assuming you have one) are the entries in the Motif order
> with the correct Motif mnemonics and accelerators?  Are those the
> same as the ones specfied for Open Look?

OL doesn't care.  Specify them for Motif and you satisfy both.

> When you bring up a 
> dialog box which the user may want to keep around (Query, for
> instance, in our mail application) do you put an Apply button in the
> dialog for Motif and a Pushpin for Open Look?

As has been mentioned before, this is an area where motif simply has bad
design.  It totally breaks down when you have dialog boxes with more than
one option other than cancel.  The number of apply buttons you need turns out
to be 2*n-1, as in:
	Write to File
	Write to File with Backup
	Cancel
Using the Apply, you need:
	Write to File
	(Apply) Write to File
	Write to File with Backup
	(Apply) Write to File with Backup
	Cancel.
It's a classis case of bad design.  Any time you have a function which reads
like "do this AND that", it should be broken into two distinct functions.
The pushpin supplies the samantics for one of those functions.

What to do about it?  I would recommend using the semantics to put a pushpin
on the dialog box, then beating on your toolkit vendor (If you're using OI,
that's us) to provide you equivalent semantics in the Motif case.  If you
have a toolkit vendor seriously concerned about addressing the needs of their
users, you'll see some response in a reasonable time frame.

> Is Mouse Button 3
> the "display popup" button in both Motif and Open Look?

Yes.

> And given that all of that works, do you have the underlying
> access to the toolkit that allows you to do things like have
> context-sensitive popups

Not sure what you mean here.

> cache commonly used dialogs and windows

Trivial

> put in timeouts so that the screen is updated before
> an operation occurs

Trivial

> modify an interface object so it doesn't
> take up as much room (or behaves slightly differently)

Yep.

> change
> the translations in text widgets so that tab in a readonly text
> widget goes to the next field instead of inserting.

Yep.

> And of
> course have it all work in both toolkits?

Yep.  In fact, the OI resource mechanism is more versatile than that for
Xt based toolkits, since it allows specification based on 
	The toolkit	(OI)
	The model	(Motif, OpenLook, 3D Openlook)
	The screen	number
	mono/color
	language

> This stuff about being able to do two GUIs is nonsense.

I suppose if you have a vested interest in a particular GUI, that's how you
would look at it.  But if you are an ISV and would like to maximize your
potential market while minimizing your resource expenditures for
development/maintenance, you wouldn't look at it that way.

>  But simply because WE SHOULDN'T HAVE TO DO IT!

Agreed.  But given that neither camp appears very motivated to roll over and
play dead, I'd say it's a fact of life for a while.
-- 
Gary Aitken

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