Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!mintaka!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: comp.windows.x Subject: Re: OPEN LOOK announced first (was: Re: Motif/Openlook, is there a trend? Message-ID: <1991Feb5.055318.4150@alphalpha.com> Date: 5 Feb 91 05:53:18 GMT References: <1991Jan23.164403@ecovsb.ncsu.edu> <2977@sodium.ATT.COM> <1991Jan30.211330.12990@sq.sq.com> <1991Feb3.025211.8461@alphalpha.com> Organization: asi Lines: 85 In article toml@marvin.Solbourne.COM (Tom LaStrange) writes: >It must be Monday :-) > > Decision Criteria Added After the Membership Feedback Meeting > Intrinsics Based Solution [based on a desire for an object-oriented > approach and previous moves in this direction by NIST and X/Open]. > Implementation Language [stick with C for now, not C++]. > Open Architecture [viable for at least 5 years] > >Aren't "object-oriented" and "C" mutually exclusive? Here's a great quote Obviously not, since most implementations of C++ create C :-). Let me quote further: Some of the membership thought that a solution based on an object- oriented programming language was desirable. However, X/Open and NIST, two important standards bodies, had already decided to adopt the MIT X intrinsics level as a base for further standarization efforts. These intrinsics provide an object-oriented approach to interface tookits, based on the C programming language. The staff decided that while a language-based multiple-inheritance, object-oriented solution would be important for the future, at this time it was more important to conform in the direction set by the standards bodies. >"C is inadequate for object oriented programming" No arguments there. Thus the word "approach". Me, I write my Motif code in C++. > For the record, I'll state again that I think Sun's biggest mistake > was in trying to release N toolkits on the unsuspecting world. It's > all very fine to say Open Look is toolkit independant - so's Motif, and > there are at least four Motif-compliant (to one extent or another) > toolkits in existance* - but OSF is only selling one, and there's only > one which I have to worry about being supported when I move from > platform to platform. With Open Look I have no idea which the vendor > will support. Does _Sun_ even claim to support anything other than > XView? I doubt it. Their version of libXt.a has pathnames that > point at /usr/lib/X11, but the version of SunOS4.0 I've used doesn't > even have that directory. That doesn't look like support to me. > >I love this statement. The ONLY Motif-compliant toolkit is the one produced >by OSF. I don't want to speak for OSF and they can correct me if their >policies have changed but OSF will not and has no plans to certify other >toolkits as "Motif-compliant". There are a number of levels of compliance. There are Motif compliant applications. They clearly can and have been produced by other toolkits. The second level of compliance is a toolkit that complies with the Motif AES (Application Environment Specification). I can certainly conceive of a (say) C++-based toolkit which provided it's own interface, but also provided a set of layered routines which met the AES. And if you had one, I'm sure that you could get it branded compliant. Practically speaking you'd have to worry about doing some of the Xt calls too though. I'm not sure how you'd certify the toolkit beyond that. I guess that Sun does it with Open Look, but it clearly must involve a fair amount of effort. Given the lack of people at OSF, I'd certainly expect them to put their resources elsewhere. >I asked an OSF person last October if they planned on certifying any other >toolkits and the response was: > > "Why would we want to do that?" From their perspective that's not an unreasonable question. What did you say? >The only thing those of us struggling to provide a Motif-like toolkit can >say is that you can write Motif compliant applications with the toolkit. >That's it. As a toolkit user that's almost enough for me. Tell me that you provide equivalents of all of the Motif primitive widgets, a set of constraint managers which don't require absolute positioning and that all widgets fully support the style guide (keyboard traversal and mnemonics are two biggies that most miss) and I'll be happy. Tell me I can have the source can easily port it to any machine I port my app too and I might even buy it. I'm no great fan of the Intrinsics. My main toolkit constraint right now is that I've got to have source. I can't wait around for someone else to do a port. -kee -- 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.