dieter@ixos (02/12/91)
Toolkit for Open Look *and* OSF/Motif Look and Feel We are searching for a special toolkit for the development of graphical user interfaces(GUI) based on the X Window System. This toolkit should allow to get the Look and Feel of both toolkits, namely OSF/Motif and Open Look, out of one single applikation programming interface(API)! "OSF/Motif" UI / / single API < \ \ "Open Look" UI We have been told, that there are existing solutions, e.g. one of the Solbourne Company, mentioned in a product announcement of AT&T. Who can give information about this or other toolkits with the described possibilities? Thank you for your answers. Please reply by email to *----------------------------------------------------------------------* Dieter Tremel | uunet!unido!ixos!dieter iXOS Software GmbH | or Bretonischer Ring 12 | dieter@ixos.uucp 8011 Grasbrunn/Muenchen - West Germany | *----------------------------------------------------------------------*
marbru@attc.UUCP (Martin Brunecky) (02/15/91)
In article <1322@ixos.de> dieter@ixos () writes: >Toolkit for Open Look *and* OSF/Motif Look and Feel > >We are searching for a special toolkit for the >development of graphical user interfaces(GUI) based on the X Window System. >This toolkit should allow to get the Look and Feel of both toolkits, >namely OSF/Motif and Open Look, >out of one single applikation programming interface(API)! > 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". However. Keep in mind that you are asking for almost impossible. The UI "styles" mentioned above have significant differences in the overall structure, layout and philosophy (though in many aspect both are pretty close). Most "toolkits" provide COMPONENTS, and make it APPLICATION responsibility to use those components according to their Style Guide / Specification. So while you may find a toolkit that will provide the same API to (lets say) pushbutton which can be toggled between Motif and Open Look look and feel (behavior), the way HOW and WHERE you are supposed to use this pushbutton may vary significantly. As a result, the application layer in charge of UI *may* be completely different. I am saying *may* because it depends on the application. Where the UI is very simple, chances are that the application layer may be (almost) identical. Probably the best way to find out where a particular application stands is to take two guys with a paper and pencil, and let one of them sketch the UI using Motif Style Guide, the other one using Open Look specification. You may find out that a single API (though very desirable just from the learning curve standpoint) may buy you much less than you expect. Using high level UIMS may be a different ballgame. But so far I haven't seen one that would be so "high level". -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (02/15/91)
> We are searching for a special toolkit for the > development of graphical user interfaces(GUI) based on the X Window System. > This toolkit should allow to get the Look and Feel of both toolkits, > namely OSF/Motif and Open Look, > out of one single applikation programming interface(API)! Look into Wcl, the Widget Creation Library. The API is basically widget set independent. Your application can take full advantage of both OLIT and Motif widget sets. Obviously, the user interfaces will be somewhat different. The C code *can* be identical. The way it works is simple: Wcl allows the entire widget interface to be specified in Xrm resource files. You always could specify all the widget attributes in resource files (color, font, label, ...), and bindings from events to action routines (translations). Wcl adds just a little code to allow the widget types, widget hierarchy, and callbacks to be bound via the resource file. The result is that your C code consists of a very simple main() routine and then all of your actions and callbacks. You don't write any XtSetArg, XtSetValue, and XtCreateWidget code at all. The latest version of Wcl, version 1.05, is available via ftp from JPL and from MIT as well as comp.sources.x archive sites. site name internet id compressed tar file name --------- ------------- ------------------------ devvax.jpl.nasa.gov 128.149.1.143 /pub/Wcl/Wcl.1.05.tar.Z expo.lcs.mit.edu 18.30.0.212 /contrib/Wcl.1.05/Wcl.1.05.tar.Z Here is sorta how to get Wcl using ftp: % mkdir Wcl % cd Wcl % ftp devvax.jpl.nasa.gov ftp login: anonymous ftp passwd: <type in your login name and host> OK ftp> cd pub/Wcl ftp> binary ftp> get Wcl.1.05.tar.Z ftp> quit % uncompres Wcl.1.05.tar.Z % tar xvf Wcl.1.05.tar % more README If you can't get it by ftp, then bug your system administrator. If that still doesn't work, then I'll mail you the shar files. ------------------------------------------------------------------------- David Smyth david@jpl-devvax.jpl.nasa.gov Senior Software Engineer, seismo!cit-vax!jpl-devvax!david X and Object Guru. (818)393-0983 Jet Propulsion Lab, M/S 230-103, 4800 Oak Grove Drive, Pasadena, CA 91109 ------------------------------------------------------------------------- "There was a time when man would attribute everything he didn't understand to God. Now, with our heightened understanding of science, we attribute them to UFO's." -Gary Friedman -------------------------------------------------------------------------
dieter@ixos (02/15/91)
Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel Thank You for your answers to my Question about the toolkits for Open Look and OSF/Motif Look and Feel. The information I got was a helpful step forward for the solution of our problem. I repost the answers I received by email in the rest of this article. My question was: >> Toolkit for Open Look *and* OSF/Motif Look and Feel >> >> We are searching for a special toolkit for the >> development of graphical user interfaces(GUI) based on the X Window System. >> This toolkit should allow to get the Look and Feel of both toolkits, >> namely OSF/Motif and Open Look, >> out of one single applikation programming interface(API)! >> >> >> "OSF/Motif" UI >> / >> / >> single API < >> \ >> \ >> "Open Look" UI >> >> We have been told, that there are existing solutions, e.g. one of the >> Solbourne Company, mentioned in a product announcement of AT&T. >> >> Who can give information about this or other toolkits with the >> described possibilities? Thank you for your answers. >> >> Please reply by email to Thanks a lot, Dieter Tremel *----------------------------------------------------------------------* Dieter Tremel | uunet!unido!ixos!dieter iXOS Software GmbH | or Bretonischer Ring 12 | dieter@ixos.uucp 8011 Grasbrunn/Muenchen - West Germany | *----------------------------------------------------------------------* ****************************************************************************** repost repost repost repost repost repost repost repost repost repost ****************************************************************************** Return-Path: <craig%utcs.utoronto.ca@guug.de> Received: by ixos.de (sendmail 5.61) id AA00363; Fri, 15 Feb 91 08:00:26 +0100 Received: by guug.guug.de (5.57/GUUG-V3.0) id AA06478; Fri, 15 Feb 91 07:33:50 MEZ Received: from unido.Informatik.Uni-Dortmund.DE by tumuc.regent.e-technik.tu-muenchen.de with SMTP (5.61++L2/TUMUC-V3.17) id AA26319; Fri, 15 Feb 91 07:30:42 +0100 Received: from gpu.utcs.utoronto.ca by unido.informatik.uni-dortmund.de with SMTP (5.65+/UNIDO-2.0.3.e) via EUnet for tumuc.regent.e-technik.tu-muenchen.de id AA12598; Fri, 15 Feb 91 06:31:34 GMT Received: by gpu.utcs.utoronto.ca id <18664>; Fri, 15 Feb 1991 01:30:16 -0500 >From: Craig Hubley <craig@utcs.utoronto.ca> To: dieter@ixos.de Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel Newsgroups: comp.windows.x,comp.windows.x.motif,comp.windows.open-look In-Reply-To: <1322@ixos.de> Organization: UTCS Public Access Message-Id: <91Feb15.013016est.18664@gpu.utcs.utoronto.ca> Date: Fri, 15 Feb 1991 01:30:03 -0500 The library you are looking for is called OI (Object Interface) and it is indeed by Solbourne. AT&T is distributing it with C++ as an added- value product. Note that you *must* use C++ as this is a C++ library that cannot run under C. It makes heavy use of C++'s object-oriented features. Learning C++ isn't too much of a burden for a good C programmer. In fact it is *more* difficult for an expert C programmer, because while the C++ language is a superset of C, good C++ design involves unlearning a lot of what was desirable in structured programming. As a C++ instructor, and a consultant on user interfaces, I can say with some confidence that you should not find OI difficult to use once you understand C++. But be prepared to take a course and devote a couple of weeks to learning your way around it. C++ is going through ANSI standardization in the US and probably ISO standardization soon after that - it is a quite mature language at this point, although some features will probably be added. Hope this helps, Craig Hubley "...get rid of a man as soon as he thinks himself an expert." Craig Hubley & Associates------------------------------------Henry Ford Sr. craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig 28 First Avenue, Toronto, Ontario M4M 1W8 Canada Voice: (416) 466-4097 Return-Path: <amanda%visix.com@guug.de> Received: by ixos.de (sendmail 5.61) id AA12613; Fri, 15 Feb 91 00:32:52 +0100 Received: by guug.guug.de (5.57/GUUG-V3.0) id AA02516; Fri, 15 Feb 91 00:25:14 MEZ Received: from unido.Informatik.Uni-Dortmund.DE by tumuc.regent.e-technik.tu-muenchen.de with SMTP (5.61++L2/TUMUC-V3.17) id AA18617; Fri, 15 Feb 91 00:22:00 +0100 Received: from mcsun.EU.net by unido.informatik.uni-dortmund.de with SMTP (5.65+/UNIDO-2.0.3.e) via EUnet for regent.regent.e-technik.tu-muenchen.de id AA06383; Thu, 14 Feb 91 23:22:50 GMT Received: by mcsun.EU.net via EUnet; id AA12497 (5.65a/CWI-2.72); Fri, 15 Feb 91 00:21:40 +0100 Received: from microbus.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA18550; Thu, 14 Feb 91 18:13:41 -0500 Received: from nsx.visix.com by visix.com (4.1/VSX-0.8) id AA06344; Wed, 14 Feb 90 17:39:35 EST Received: by nsx.visix.com (5.61/SMI-4.1) id AA12502; Thu, 14 Feb 91 17:39:21 -0500 Date: Thu, 14 Feb 91 17:39:21 -0500 >From: amanda@visix.com (Amanda Walker) Message-Id: <9102142239.AA12502@nsx.visix.com> To: dieter@ixos.de Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel Newsgroups: comp.windows.x,comp.windows.x.motif,comp.windows.open-look In-Reply-To: <1322@ixos.de> Organization: Visix Software Inc., Reston, VA In article <1322@ixos.de> you write: >We are searching for a special toolkit for the development of >graphical user interfaces(GUI) based on the X Window System. This >toolkit should allow to get the Look and Feel of both toolkits, >namely OSF/Motif and Open Look, out of one single applikation >programming interface(API)! We (Visix Software Inc.) have such a toolkit. We have been using it in our own products for several years, and we will be offering it for sale to the general public this summer. It provides the following `look and feel' standards: OSF Motif Open Look (2D & 3D) IBM CUA (similar to Microsoft Windows or Presentation Manager) on the following window systems: X Window System version 11 SunView Intergraph Environ V It currently runs on 45 different combinations of workstation hardware and window system software, with additional ports in progress. The look and feel is selectable at runtime by the user. The toolkit is very small and fast, compared to other user interface toolkits, especially ones based on X widgets. For example, our major product (a visual desktop environment called "Looking Glass") has a smaller binary on many systems than the Motif window manager alone. If you would like more information, please feel free to contact me: Amanda Walker Visix Software, Inc. 11440 Commerce Park Drive Reston, VA 22901 USA +1 703 758 8230 (voice) +1 703 758 0233 (fax) Return-Path: <dow%presto.ig.com@guug.de> Received: by ixos.de (sendmail 5.61) id AA08429; Thu, 14 Feb 91 18:09:56 +0100 Received: by guug.guug.de (5.57/GUUG-V3.0) id AA21595; Thu, 14 Feb 91 17:48:22 MEZ Received: from unido.Informatik.Uni-Dortmund.DE by tumuc.regent.e-technik.tu-muenchen.de with SMTP (5.61++L2/TUMUC-V3.17) id AA12961; Thu, 14 Feb 91 17:45:10 +0100 Received: from mcsun.EU.net by unido.informatik.uni-dortmund.de with SMTP (UNIDO-2.0.3.e) via EUnet for regent.regent.e-technik.tu-muenchen.de id AA12486; Thu, 14 Feb 91 14:18:38 GMT Received: by mcsun.EU.net via EUnet; id AA06080 (5.65a/CWI-2.72); Thu, 14 Feb 91 15:17:25 +0100 Received: from presto.ig.com by uunet.uu.net (5.61/1.14) with SMTP id AA05399; Thu, 14 Feb 91 09:09:57 -0500 Received: by presto.ig.com (5.61/1.15) id AA06638; Thu, 14 Feb 91 06:08:13 -0800 Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.presto.ig.com.sun3.4 via MS.5.6.presto.ig.com.sun3_4; Thu, 14 Feb 91 06:08:12 -0800 (PST) Message-Id: <QbidbAS6f08E8L8GN9@presto.ig.com> Date: Thu, 14 Feb 91 06:08:12 -0800 (PST) >From: Christopher Dow <dow@presto.ig.com> To: dieter@ixos.de Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel In-Reply-To: <1322@ixos.de> References: <1322@ixos.de> XVT Software, Inc. 1800 30th St. Box 17665 Boulder, CO 80308 USA Tel. (303)443-4223 Fax(303)443-0969 The product is called XVT, and is available for Motif now, and will be available (in beta form) for OpenLook in about two months. I've used this product and other versions of it (Mac, Windows, etc.) for two years now and love it. Good Luck Chris Dow IntelliGenetics Software Engineer 700 East El Camino Real icbmnet: 37 22' 39" N, 122 3' 32" W Mountain View, Ca. 94040 dow@presto.ig.com (415) 962-7320 Return-Path: <fein%informatik.uni-kl.de@guug.de> Received: by ixos.de (sendmail 5.61) id AA08424; Thu, 14 Feb 91 18:09:54 +0100 Received: by guug.guug.de (5.57/GUUG-V3.0) id AA21562; Thu, 14 Feb 91 17:47:22 MEZ Received: from unido.Informatik.Uni-Dortmund.DE by tumuc.regent.e-technik.tu-muenchen.de with SMTP (5.61++L2/TUMUC-V3.17) id AA12942; Thu, 14 Feb 91 17:43:56 +0100 Received: from uklirb.informatik.uni-kl.de by unido.informatik.uni-dortmund.de with SMTP (UNIDO-2.0.3.e) via EUnet for tumuc.regent.e-technik.tu-muenchen.de id AA10894; Thu, 14 Feb 91 14:00:29 GMT Date: Thu, 14 Feb 91 14:50:33 MET >From: Frank Fein <fein@informatik.uni-kl.de> To: dieter@ixos.de Subject: Re: Toolkit for Open Look *and* OSF/Motif Look and Feel Message-Id: <9102141450.aa15068@uklirb.informatik.uni-kl.de> In article <1322@ixos.de> you write: >Toolkit for Open Look *and* OSF/Motif Look and Feel > >We are searching for a special toolkit for the >development of graphical user interfaces(GUI) based on the X Window System. >This toolkit should allow to get the Look and Feel of both toolkits, >namely OSF/Motif and Open Look, >out of one single applikation programming interface(API)! >We have been told, that there are existing solutions, e.g. one of the >Solbourne Company, mentioned in a product announcement of AT&T. > >Who can give information about this or other toolkits with the >described possibilities? Thank you for your answers. > Solbournes OI (Open Interface Library, wird von AT&T vertrieben, Solbourne- Vertrieb in Deutschland zum Beispiel Ractech in Bad Honnef) arbeitet mit dem Resource Manager. Der Anwender bekommt ein Objektprogramm und kann nach Lust und Laune ueber .Xdefaults bestimmen, ob er Motif oder OL moechte. Dann gibt's noch XVT (X Virtual Toolkit von Marc Rochkind et al., in Europa von Decos Software, Sandtlaan 36, NL-2223 GG Katwijk, Tel. 01718-51403 vertrie- ben). Da wird pro unterstuetzter Oberflaeche ein Objekt erstellt, indem man sich die entsprechende XVT-Library kauft und dazubindet. OI ist angeblich eher Open Look-orientiert, Motif-Support schreitet aber angeb- lich voran. Bei XVT ist es umgekehrt: dort wurde Open Look noch nicht voll un- terstuetzt. (Informationsstand: 10.90) Ausserdem gibts noch zwei neuere Produkte aus den USA, die vor kurzem hier erwaehnt wurden, mir aber leider entfallen sind :-( -- ______ Frank Fein; DFKI GmbH _/______ P.O. Box 2080 / _/_ D-6750 Kaiserslautern <Phone>: +49 6 31 205-34 80 / West Germany <E-Mail>: fein@dfki.uni-kl.de
toml@marvin.Solbourne.COM (Tom LaStrange) (02/15/91)
> We are searching for a special toolkit for the > development of graphical user interfaces(GUI) based on the X Window System. > This toolkit should allow to get the Look and Feel of both toolkits, > namely OSF/Motif and Open Look, > out of one single applikation programming interface(API)! > > > "OSF/Motif" UI > / > / > single API < > \ > \ > "Open Look" UI > > We have been told, that there are existing solutions, e.g. one of the > Solbourne Company, mentioned in a product announcement of AT&T. > > Who can give information about this or other toolkits with the > described possibilities? Thank you for your answers. A Postscript copy of the OI (the Solbourne toolkit) tutorial is available on expo.lcs.mit.edu in contrib/OItutorial.tar.Z. Here's the standard blurb about the toolkit with the name of the AT&T contact. The OI toolkit is a C++ based toolkit for writing X11 applications. It has been licensed and is being distributed by AT&T. Like other toolkits, OI provides a basic set of objects used in constructing a user interface. Unlike other toolkits, these objects are generic in nature. The particular appearance and behaviour of an object may be determined at execution time -- the same executable image may run under different interaction and appearance models. OI currently supports Motif, and 2D and 3D OPENLOOK. Subclassing to produce user derived classes which will work in all models is easy to accomplish. Paul Fillinich attmail!pfillinich@attunix.att.com AT&T USL 1-800-828-UNIX -- Tom LaStrange toml@Solbourne.COM
janssen@parc.xerox.com (Bill Janssen) (02/19/91)
In article <11445@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes:
The result is that your C code consists of a very simple main() routine
and then all of your actions and callbacks. You don't write any XtSetArg,
XtSetValue, and XtCreateWidget code at all.
Well, you do, but you do it in the declarative language used by Wcl.
Bill
--
Bill Janssen janssen@parc.xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304amanda@visix.com (Amanda Walker) (02/20/91)
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 :). > Keep in mind that you are asking for almost impossible. I wouldn't go that far... > The UI "styles" mentioned above have significant differences in the > overall structure, layout and philosophy (though in many aspect > both are pretty close). Agreed. This is what makes it challenging, though :). > Most "toolkits" provide COMPONENTS, and make it APPLICATION > responsibility to use those components according to their Style > Guide / Specification. Again, agreed. However, I view this as a shortcoming of current toolkits, not of the idea of a uniform API to multiple user interface styles in and of itself. Personally, I don't think an application should have to worry about user interface policy--the user should be able to pick what they want to use. Likewise, application developers should not have to worry about "who's winning the GUI war." They should just be able to write an application, and have their users decide what flavor of interface they want to use. 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. Part of the problem, also, is that current "toolkits" are focused on individual user interface elements, and not overall organization of the interface. Thus, Xm and OLIT are basically "sacks of parts" that applications can use to construct a user interface--they do not actually implement either Motif or Open Look, a task that is left up to the application developer. They are better than nothing, but they still put too much burden on the application. Disclaimer: I get paid to change this situation :). -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- For every vision, there is an equal and opposite revision.
lance@motcsd.csd.mot.com (lance.norskog) (02/20/91)
Some guy at the Strategic Air Command in Rome, New York wrote a C++
class library that controls OL and Motif. It's called THINGS.
I got it from the ZOK UUCP X sources archive, which also has Thomas
Roell's new 1.1 386 port of X11R4. Here's an old read-me:
#########################################################################
################# A n n o u n c i n g #################
################# W e s t C o a s t #################
################# U U C P X 1 1 A r c h i v e #################
#########################################################################
Good News: We now have a UUCP X11 archive site on the west coast again.
The X archive on Zok contains the full X11R4 distribution, the XTEST
distribution, an *entire* archive of comp.sources.x, along with many
other X11 goodies.
To get a current listing of the files that are available, download
the file "/usrX/ls-lR.Z".
A full subject index of the comp.sources.x files is available in the
file "/usrX/comp.sources.x/INDEX".
When downloading files with uucp, wildcards (i.e. "*") won't work. Be
sure to specify the full pathname starting with "/usrX/". For example,
uucp zok\!/usrX/ls-lR.Z \!~
(The above "\"'s are csh escapes, ignore them if you're using sh.)
Currently this modem line is Zok's only email and news connection to
the outside world. Should you wish to fetch large distributions, such
as X11R4, it would be appreciated if you would pause every now and then
so that normal UUCP traffic may continue. Thanks.
-- Mark
Mark W. Snitily Consulting Services:
894 Brookgrove Lane Graphics, Operating Systems, Compilers
Cupertino, CA 95014 (408) 252-0456
mark@zok.uucp
Zok, one of the distant planets occasionally visited by
"Spaceman Spiff," Conqueror of the Cosmos,
Bold Interplanetary Explorer,
Interplanetary Explorer Extraordinaire.
(Also known as Calvin, of "Calvin and Hobbes.")toml@marvin.Solbourne.COM (Tom LaStrange) (02/21/91)
} >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++. How do you signal a failure when using a constructor? The oi_create*** routines basically do a "new" with additional checks to ensure all of the object's resources were allocated (bitmap files, fonts, etc.) If the object could not be constructed, a NULL is returned and all resources that were allocated are freed. -- Tom LaStrange toml@Solbourne.COM
brsmith@cs.umn.edu (Brian R. Smith) (02/21/91)
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 |
sarahh@csn.org (Sarah Howard) (02/21/91)
Is there a way to activate a callback function by pressing the right mouse button in Motif? Sarah Howard
imp@Solbourne.COM (Warner Losh) (02/21/91)
In article <1991Feb20.170617.15372@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >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. After writing many OI programs, I have not found a case where I had to put something like if (I'm in motif) do brain-dead things else if I'm in Openlook do other brain-dead things in any of the code that I have written. Modulo funky "look", the Openlook and Motif style guides are not really that different. There are many "feel" issues that the toolkit takes care of and that I as a toolkit user need never worry about. It may take some careful planning, but it usually isn't that big an issue. >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. In OI there are many different types of scrolled objects. The application writer can either tell the scolled object to have scroll bars in a specific place (like on the left and to) or tell it to user a vertical scroll bar and the toolkit will place it based on what GUI the user selected. Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
nazgul@alphalpha.com (Kee Hinckley) (02/21/91)
In article <TOML.91Feb20110922@marvin.Solbourne.COM> toml@marvin.Solbourne.COM (Tom LaStrange) writes: >How do you signal a failure when using a constructor? The oi_create*** >routines basically do a "new" with additional checks to ensure all of the >object's resources were allocated (bitmap files, fonts, etc.) If the object >could not be constructed, a NULL is returned and all resources that were >allocated are freed. I put code in the new handler to free stuff up and signal an error? How much of your code actually checks for the return value from oi_create and does something reasonable with it? How often is that something more than mapping a (cached) window and saying, "Sorry, out of memory."? I'm not saying the oi_create stuff is wrong, but I'm not convinced it's worth the trouble. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
brsmith@cs.umn.edu (Brian R. Smith) (02/22/91)
In <TOML.91Feb20110922@marvin.Solbourne.COM> toml@marvin.Solbourne.COM (Tom LaStrange) writes: >} 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. >How do you signal a failure when using a constructor? The >oi_create*** routines basically do a "new" with additional checks to >ensure all of the object's resources were allocated (bitmap files, >fonts, etc.) If the object could not be constructed, a NULL is >returned and all resources that were allocated are freed. If a new fails, a zero is returned. In the constructor for an object (called after the new, or anytime an instance of that object enters scope) you can allocate and check for the resources you mention. If the allocations fail, you can then (if the object was created via new) delete it and return zero. If you're not using pointers to objects, you would probably want to have some member function to verify that the object was initialized successfully. But, the current scheme could be nearly identical with constructors. And more intuitive, IMHO. -- Brian | <This space intentionally left almost blank.> brsmith@cs.umn.edu |
brsmith@cs.umn.edu (Brian R. Smith) (02/22/91)
In <1991Feb20.194928.3022@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes: >In article <1991Feb20.170617.15372@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >>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. >After writing many OI programs, I have not found a case where I had to >put something like > if (I'm in motif) > do brain-dead things > else if I'm in Openlook > do other brain-dead things >in any of the code that I have written. Modulo funky "look", the >Openlook and Motif style guides are not really that different. There >are many "feel" issues that the toolkit takes care of and that I as a >toolkit user need never worry about. It may take some careful >planning, but it usually isn't that big an issue. Hmmm. But don't you have to limit yourself to a set of objects that are common to both toolkits? What happens to command (push-pin) windows under Motif, for instance? >>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. >In OI there are many different types of scrolled objects. The >application writer can either tell the scolled object to have scroll >bars in a specific place (like on the left and to) or tell it to use >a vertical scroll bar and the toolkit will place it based on what GUI >the user selected. You hit half of my question. So, scrollable OI objects create their own scrollbars, correct? Is there support for attaching completely different scrolling devices also? Say you have an object that is scrollable both horizontally and vertically - could you dispose of the scrollbars and add a panner? Thanks for investing your time to reply - my knowledge of OI was based solely on what we got from a sales rep. -- Brian | <This space intentionally left almost blank.> brsmith@cs.umn.edu |
nazgul@alphalpha.com (Kee Hinckley) (02/22/91)
In article <1991Feb20.194928.3022@Solbourne.COM> imp@Solbourne.COM (Warner Losh) writes: >After writing many OI programs, I have not found a case where I had to >put something like > if (I'm in motif) > do brain-dead things > else if I'm in Openlook > do other brain-dead things >in any of the code that I have written. Modulo funky "look", the >Openlook and Motif style guides are not really that different. There >are many "feel" issues that the toolkit takes care of and that I as a >toolkit user need never worry about. It may take some careful >planning, but it usually isn't that big an issue. Okay. Presumbably you didn't put any buttons in the menubar, since you aren't supposed to do that in Motif. Do you have a Help pulldown in the menubar? 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? 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? Is Mouse Button 3 the "display popup" button in both Motif and Open Look? 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, cache commonly used dialogs and windows, put in timeouts so that the screen is updated before an operation occurs, modify an interface object so it doesn't take up as much room (or behaves slightly differently), change the translations in text widgets so that tab in a readonly text widget goes to the next field instead of inserting.... And of course have it all work in both toolkits? This stuff about being able to do two GUIs is nonsense. Not because it isn't possible. Not because it isn't easy. But simply because WE SHOULDN'T HAVE TO DO IT! It's a waste of time, resources and it hurts the industry. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
imp@Solbourne.COM (Warner Losh) (02/22/91)
In article <1991Feb21.173041.17254@cs.umn.edu> brsmith@cs.umn.edu (Brian R. Smith) writes: >Hmmm. But don't you have to limit yourself to a set of objects that >are common to both toolkits? What happens to command (push-pin) >windows under Motif, for instance? Well, the OI library has lots of objects that map to different widgets in Openlook or Motif. The Command window under motif is supplied as an OI object, so I can use it and know that OI will do something reasonable when the program gets run in Openlook. There are many places where OI will provide a superset of both look and feels and do the right thing in the look and feel whose style guide doesn't talk about that particular interaction. >You hit half of my question. So, scrollable OI objects create their >own scrollbars, correct? Yes. There are three scrollable objects: Scroll Text, Scroll Menus, and Scroll Box. The latter is basically a scrolling container that you just stuff objects into. Perfect for your Graphics Editor application. In addition, we provide a scroll bar and panner so you can create your own scrollable objects if the pre-cooked ones don't fit your needs. >Is there support for attaching completely different scrolling devices >also? Say you have an object that is scrollable both horizontally and >vertically - could you dispose of the scrollbars and add a panner? If the programmer wants scroll bars, then he can specifiy scroll bars. If the programmer feels that a panner would be better, then he/she can specify a panner rather than scroll bars. There are even hooks in the scrollable objects to allow any control that the programmer can think of. Warner P.S. Where does this discussion belong? -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
zoo@aps1.spa.umn.edu (david d [zoo] zuhn) (02/24/91)
>>>>> On 21 Feb 91 18:48:26 GMT, nazgul@alphalpha.com (Kee Hinckley) said:
Kee> This stuff about being able to do two GUIs is nonsense. Not because
Kee> it isn't possible. Not because it isn't easy. But simply because
Kee> WE SHOULDN'T HAVE TO DO IT! It's a waste of time, resources and it
Kee> hurts the industry.
Well, I agree with you entirely on that one. I assume that you are
now going to drop all of your Motif support and move over into the OL
camp.
Supporting multiple UI's doesn't hurt the industry any more so than
any one side being declared the winner and the opponents being
relegated to /dev/null before they've fully duked it out.
There are valid reasons for supporting Motif. There are valid reasons
for supporting OL. The previous two sentences are valid reasons for
supporting work like OI which gives the user a chance to choose.
I don't want this to turn into yet another my-GUI-blows-your-GUI-out-of-
the-water discussion, which will lead nowhere. Let's continue
discussion about how we can support multiple GUI's in a single API.
david d [zoo] zuhn Univ. of Minnesota Dept. of Astronomy
zoo@aps1.spa.umn.edu Automated Plate Scanner Projectamanda@visix.com (Amanda Walker) (02/26/91)
brsmith@cs.umn.edu (Brian R. Smith) writes: >Ack! An unbeliever! :-) >I don't understand why they didn't use constructors, and my first >guess is that the implementor wasn't completely comfortable with C++. This was my impression as well. OI, while it uses C++ object inheritance, still seems pretty C-oriented stylistically. And if you're going to use C style, you might as well use C, as far as I'm concerned. To me, C++ isn't worth it to gain a *little* bit of leverage; it's only worth doing if it's a fairly big win. I agree that InterViews gains a lot more from C++, comparatively speaking. >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. Well, most L&F specs are functionally oriented. Taking a functional view of the API helps a whole lot here. >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. This doesn't seem intractable to me. It just shows that you need a generic "editing area" abstraction. As an example of this, one of the standard items in our toolkit is, roughly, "a scrolling view of an ordered stack of 2-D object extents." Sort of like a drawing program that doesn't actually draw anything itself (like, zen, eh?). The application doesn't worry about how to scroll, or manage selections, or stacking order, or whatever. It describes the behavior it wants, and supplies code to customize some actions (like drawing individual objects, etc.). It doesn't care where the scroll bars are, or even how scrolling is handled at all--the L&F could just as easily specify that Alt-mouse-drag did scrolling. This is the sort of thing I mean when I say that having to know about the L&F (at an application level) shows that the API needs to be improved. The application should (IMNSHO) take a purely functional view of how the interface is presented to the user. Insofar as that interface is affected by the L&F, it should be implemented at the toolkit layer, not in the application itself. >Trying to make a toolkit that understands application-by-application >foibles is hard. Yes. > Extending the toolkit to include the objects YOUR >application requires makes much more sense to me. This seems to be a somewhat separate issue to me. >So you need a toolkit that is easily extensible. >Yay for C++ and subclassing... Well, C++ isn't the only way to do subclassing. It's not even the only easy way (although I will grant that Xt's approach is pretty unwieldy). We use a bare-bones template based system that fits well into "vanilla" C code, for example. It gives us what we want with a minimum of baggage. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "Furious activity is no substitute for understanding." --H. H. Williams
amanda@visix.com (Amanda Walker) (02/26/91)
toml@marvin.Solbourne.COM (Tom LaStrange) writes: >How do you signal a failure when using a constructor? The same way you signal any other failure... Uh, you *do* have an exception handling scheme, don't you? Using magic return codes is so ... passe :). Which, actually, brings me to another point. We've found that using an Ada-style (well, MacApp-style, actually) exception handler really cleans up our code, and makes it more robust at the same time. This is another problem I have with C++, since it is much harder to write a library for it than it is in C. Ideally, you'd want destructors to get called even when a scope is exited via an exception. Of course, you can always do it C-style, but then what's the point of using C++? -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "This is a basic principle of the universe known as `The Law of the Cussedness of Nature.'" --W. Kauzmann
amanda@visix.com (Amanda Walker) (02/26/91)
>This stuff about being able to do two GUIs is nonsense. Not because >it isn't possible. Not because it isn't easy. But simply because >WE SHOULDN'T HAVE TO DO IT! It's a waste of time, resources and it >hurts the industry. <please excuse me if I sound a little testy here...> Then what exactly should we do? There is no single standard, except perhaps in the Mac market (which is rather healthy because of it...but I digress). Should I have to tie my own success to a gamble on which "standards body" is going to win the marketing wars? Should I have to limit the market for my software to selected pieces of a fragmented marketplace? If you think so, why? Speaking for the moment strictly as an application software developer, I don't bloody *care* whether Open Look is better than Motif, or vice versa. I just want to sell software, and I want to sell it on as many workstations as I possibly can. Multiplatform environments are a way to make that as easy as possible. I don't get to change the fact that my potential customers are running several different window systems with even more "look and feels," sometimes decided by corporate fiat. I don't want to get into internal political decisions, and I don't get to "fix the industry." I may not agree with the fact that "standards" have become nothing more that marketing buzzwords, but I still have to deal with the situation. The only alternatives I see are: - Don't write software until "the market settles down" - Limit your market on a basically arbitrary basis - Multiply your development effort in order to expand your market None of these is economically feasible in the commercial arena, or, at least, the commercial arena *I'm* in... Saying "we shouldn't have to do it" isn't very useful unless you have an alternative to suggest. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "I think you should profit from the mistakes of others. You don't live long enough to make them all yourself." -- Lowell Ferguson
imp@Solbourne.COM (Warner Losh) (02/26/91)
In article <1991Feb25.212238.4525@visix.com> amanda@visix.com (Amanda Walker) writes: >This was my impression as well. OI, while it uses C++ object >inheritance, still seems pretty C-oriented stylistically. What do you mean that OI is C-oriented stylistally? About the only part of it that I could see is that oi_create_* routines. These were done to get around some short comings in C++. Almost all other actions are performed via member functions. These functions use inheritance so the programmer can, for example, do the same things to a scrolling text object that he/she can do to the non-scrolling version of the object. In addition, the objects in the library are easily expandable via sub-classing. It is fairly easy to derive new classes of objects from pre-existing OI objects. It is a very natural way to view certain things. Implementing an mac-like file browser, for example, would use these techniques to create a class called, say, Icon that is derived from OI_box with a OI_glyph and a OI_static_text inside it. The browser would then subclass off the generic Icon to make more specific icons. OI is designed to make these sorts of things easy. It usually succeeds in its design, but like all other software, there are cases where it falls short. >>So you need a toolkit that is easily extensible. >>Yay for C++ and subclassing... > >Well, C++ isn't the only way to do subclassing. It's not even the only >easy way (although I will grant that Xt's approach is pretty unwieldy). >We use a bare-bones template based system that fits well into "vanilla" >C code, for example. It gives us what we want with a minimum of baggage. But doing it in C++ is, IMHO, a heck of a lot easier than trying to shoe horn it into C. I'd rather spend my time writing the meat of the object, rather than filling in a template and making sure that I call the right routines for the object. Then again, it sounds like this part of the thread is heading off into the Computer Language Jihad.... Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
nazgul@alphalpha.com (Kee Hinckley) (02/26/91)
In article <1991Feb25.215857.5136@visix.com> amanda@visix.com (Amanda Walker) writes: >>This stuff about being able to do two GUIs is nonsense. Not because >>it isn't possible. Not because it isn't easy. But simply because >>WE SHOULDN'T HAVE TO DO IT! It's a waste of time, resources and it >>hurts the industry. > ><please excuse me if I sound a little testy here...> > >Then what exactly should we do? There is no single standard, except perhaps Do what the customers ask for. If that's both, then you have to make a decision as to how much it's worth to you. The only problem with this is that some vendors are rumoured to not give you any support unless you do what *they* want. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
sarima@tdatirv.UUCP (Stanley Friesen) (02/27/91)
In article <1991Feb25.213202.4591@visix.com> amanda@visix.com (Amanda Walker) writes: <toml@marvin.Solbourne.COM (Tom LaStrange) writes: <Uh, you *do* have an exception handling scheme, don't you? ... <Which, actually, brings me to another point. We've found that using <an Ada-style (well, MacApp-style, actually) exception handler really <cleans up our code, and makes it more robust at the same time. This <is another problem I have with C++, since it is much harder to write <a library for it than it is in C. Ideally, you'd want destructors <to get called even when a scope is exited via an exception. This is exactly why the ANSI C++ committee is *seriously* considering adding exceptions to C++. [I believe that ATT's just-released cfront 3.0 contains just such a mechanism]. I am not sure if it is Ada/MacApp style of not, it is rather similar to the exception mechanism in Eiffel. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
amanda@visix.com (Amanda Walker) (02/28/91)
sarima@tdatirv.UUCP (Stanley Friesen) writes: >This is exactly why the ANSI C++ committee is *seriously* considering >adding exceptions to C++. Good ho. This will help a lot. One of the problems with C++ is that the control structures didn't catch up to the data structures :). >I am not sure if it is Ada/MacApp style of not, it is rather similar to the >exception mechanism in Eiffel. Well, I'm not very familiar with Eiffel yet. What we implement is a dynamic exception handler stack, which, in effect gives you the equivalent of Lisp's 'catch/throw/unwind-protect' primitives. That is to say, exception handlers can catch and reraise exceptions, as well as perform arbitrary actions (such as deallocating memory, for example) when their scope is exited, even for exceptions they do not otherwise handle. Fairly simple, and quite effective. Back on topic, though... some kind of exception handling (even as rudimentary as I've just described) makes both the implementation and the API of a toolkit much cleaner (not to mention the debugging benefits...). -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "Duct tape is like the force: it has a light side, and a dark side, and it holds the universe together." --Carl Zwanzig
mike@spock.atd.ucar.edu (Mike Daniels) (02/28/91)
My prediction: Open Look will win. Based on the fact that there are more Sun workstations out there than other brands and Sun is shipping the Open Look product, pre-installed, on the workstations it sells. -------------------------------------------------------------------------------- Mike Daniels (mike@spock.atd.ucar.edu) RAF/ATD/National Center for Atmospheric Research, Boulder, CO --------------------------------------------------------------------------------
amanda@visix.com (Amanda Walker) (03/01/91)
mike@spock.atd.ucar.edu (Mike Daniels) writes: >My prediction: > Open Look will win. Based on the fact that there are more Sun workstations >out there than other brands and Sun is shipping the Open Look product, >pre-installed, on the workstations it sells. Grin. But by this reasoning, SunView should have already won... And there are still a lot of machines out there still running SunView, surprising as it may seem. However, not even Sun can produce an industry consensus by brute force, however much they try :). NFS is the only clear example of it so far. There are enough "DEC shops," "IBM shops," and so on that I think the market will remain fragmented for some time. Another of my reasons for thinking so is simply that GUIs have become political issues, which means that technical merits are no longer the driving force behind "standardization" (a term I use advisedly, since it's becoming about as meaningless as "open" in this industry...). Then again, at least it's not a boring time to be alive :). -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- It is a vast and wonderful universe, but you wouldn't know it to live here.
marbru@attc.UUCP (Martin Brunecky) (03/03/91)
In article <1991Feb27.185044.24581@visix.com> amanda@visix.com (Amanda Walker) writes: > >Well, I'm not very familiar with Eiffel yet. What we implement is a >dynamic exception handler stack, which, in effect gives you the >equivalent of Lisp's 'catch/throw/unwind-protect' primitives. That is .... Sounds pretty much like VAX-VMS exception handling scheme to me (my applogy to those who can't stand VMS: I am SO sorry!) Aren't you afraid that DEC might have patent on it and will sue you just like that company with the Backing Store patent ? Mhmmm. I did not apply for a patent on Wcl. What a fool am I. Could have gotten rich and write software just for the fun of it. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
marbru@attc.UUCP (Martin Brunecky) (03/03/91)
In article <10412@ncar.ucar.edu> mike@spock.atd.ucar.edu (Mike Daniels) writes: >My prediction: > > Open Look will win. Based on the fact that there are more Sun workstations >out there than other brands and Sun is shipping the Open Look product, >pre-installed, on the workstations it sells. > My prediction: Motif will win. Based on the fact that there are more Sun workstations out there than other brands and most independent software vendors writing UIs for Sun workstations use Motif toolkit (just because then they can use the same software on less-selling workstations such as HP/Apollo, DEC and IBM). -) -) -) -) -) -) -) -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
preece@urbana.mcd.mot.com (Scott E. Preece) (03/06/91)
In article <1991Feb21.184826.11191@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: | Okay. Presumbably you didn't put any buttons in the menubar, since | you aren't supposed to do that in Motif....[more examples] --- I did think it was amusing, in an ironic kind of way, that after years of hearing (mostly OSF) people say at the P1201 meetings that the differences between Motif and OPEN LOOK were much too significant to allow an easy merger, there was a paper at Uniforum by A DEC guy that concluded "The good correspondence between the OPEN LOOK and OSF/Motif styles and toolkits indicate the general feasibility of applications supporting both GUI's." --- | This stuff about being able to do two GUIs is nonsense. Not because | it isn't possible. Not because it isn't easy. But simply because | WE SHOULDN'T HAVE TO DO IT! It's a waste of time, resources and it | hurts the industry. --- I guess I would take the unpopular side and say that both OL and Motif have profited significantly from the other's competition and that I see no reason to believe that either would have improved as fast as both have if either had been ceded the field a year ago. It's still really depressing that neither GUI has been able to significantly advance the state of the GUI art. It is a sad comment that the highest aspiration of at least one of them is to be fully compatible with the Windows Style Guide -- if we can't provide a *better*, *more productive* GUI than a PC, where is the advantage most of us have felt UNIX should have over the one-seaters? -- scott preece motorola/mcg urbana design center 1101 e. university, urbana, il 61801 uucp: uunet!uiucuxc!udc!preece, arpa: preece@urbana.mcd.mot.com phone: 217-384-8589 fax: 217-384-8550
nazgul@alphalpha.com (Kee Hinckley) (03/08/91)
In article <PREECE.91Mar6105839@etude.urbana.mcd.mot.com> preece@urbana.mcd.mot.com (Scott E. Preece) writes: >In article <1991Feb21.184826.11191@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: >| Okay. Presumbably you didn't put any buttons in the menubar, since >| you aren't supposed to do that in Motif....[more examples] >--- >I did think it was amusing, in an ironic kind of way, that after years >of hearing (mostly OSF) people say at the P1201 meetings that the >differences between Motif and OPEN LOOK were much too significant to >allow an easy merger, there was a paper at Uniforum by A DEC guy that >concluded "The good correspondence between the OPEN LOOK and OSF/Motif >styles and toolkits indicate the general feasibility of applications >supporting both GUI's." I have never said that an application can not support both GUIs. What I have said, and continue to say, is that it is not possible to fully support both GUIs using a _generic_ toolkit. There is a *big* difference between writing a GUI independant layer that is appropriate for *one* application, and writing one that is appropriate for *all* applications. I've pointed out the differences that must be dealt with, I've yet to hear anyone offer a toolkit which solves all of the problems. The best I've heard is that the differences are due to deficiencies in an implementation or Style Guide. Which may or may not be true, but in any case doesn't solve the real-world problem. Write a GUI-independant layer that solves the problem for a certain class of applications? Sure, as long as you plan ahead carefully and can deal with certain restrictions. Write one that solves it for all applications? Forget it. >| This stuff about being able to do two GUIs is nonsense. Not because >| it isn't possible. Not because it isn't easy. But simply because >| WE SHOULDN'T HAVE TO DO IT! It's a waste of time, resources and it >| hurts the industry. >--- >I guess I would take the unpopular side and say that both OL and Motif >have profited significantly from the other's competition and that I see >no reason to believe that either would have improved as fast as both >have if either had been ceded the field a year ago. I'm not sure I agree. And in any case, that doesn't take into account the wasted effort of people trying to write to two toolkits - or worse yet, not writing to either. >It's still really depressing that neither GUI has been able to >significantly advance the state of the GUI art. It is a sad comment No argument there! I'm planning on upping the technical stakes in a few weeks when I have a little more time. I've done some object-by-object comparisons of OL and Motif that I'll be posting. Stay tuned. -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
barnett@grymoire.crd.ge.com (Bruce Barnett) (03/10/91)
In article <1991Mar8.005159.7244@alphalpha.com> nazgul@alphalpha.com (Kee Hinckley) writes: > Write one that solves it for all applications? Forget it. This might be possible if you had a toolkit that had dynamic extension capability. One where you can isolate the user interaction from the application, dynamically add new event types, etc. I bet a toolkit could be developed using NeWS. I'm not sure this would help solve the problem. :-) -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett