Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!stan!marvin!toml From: toml@marvin.Solbourne.COM (Tom LaStrange) Newsgroups: comp.windows.x Subject: Re: OPEN LOOK announced first (was: Re: Motif/Openlook, is there a trend? Message-ID: Date: 6 Feb 91 15:25:41 GMT References: <1991Jan23.164403@ecovsb.ncsu.edu> <2977@sodium.ATT.COM> <1991Jan30.211330.12990@sq.sq.com> <1991Feb3.025211.8461@alphalpha.com> <1991Feb5.055318.4150@alphalpha.com> Sender: toml@Solbourne.COM (Tom LaStrange) Organization: Solbourne Computer, Inc. Lines: 149 In-Reply-To: nazgul@alphalpha.com's message of 5 Feb 91 05:53:18 GMT > In article toml@marvin.Solbourne.COM (Tom LaStrange) writes: > > 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 :-). Yup, you're right :-) > 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 toolk> it 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 guess I shouldn't have said that the ONLY motif compliant toolkit would be from OSF. Unfortunately this is where I disagree with you, I can't conceive of writing a new toolkit that also has to provide the API of the OSF version. You would probably be better off just supplying a set of wrappers on top the real thing. Doesn't the fact that you have to supply the AES mean that there will be no native Lisp, Ada, or Modula2 based motif toolkits? It seems to me that one of the factors that would lead you to choose an alternate toolkit would be because you prefer a totally different programming environment. I would like to see OSF produce a Motif toolkit compliance checklist that is API independent. This could be similar to their application checklist which would probably require fewer resources at OSF than having to verify the complete API. That is of course if they trusted toolkit makers. No organization is likely to have the resources, or the inclination, to provide toolkits for all languages users are likely to want. In particular, since the major players in OSF are almost entirely hardware vendors with staffs who deal with "well established, safe" programming languages such as C, it is unlikely that they will put significant resources into developing toolkits and interfaces for less well established languages such as C++, LISP, and things like SQL. This is all the more reason for them to produce a spec of how things look and feel to the user. It allows other software houses to develop better Motif programming environments for users working in these other environments, and thus strengthens the acceptance of Motif. The obvious example is what has happened in the OPENLOOK area, where numerous toolkits are available. The programmer can pick the one which fits the programming environment they like best. These toolkits are all learning to work together very well, not because they are all based on the same C based API, but because they all adhere to the same written specification. It's the same principle along which the X protocol spec was published. One is not required to use the MIT server. One uses the server most appropriate to the platform. Furthermore, the provider of a platform is free to implement the protocol in the most efficient manner for the system. They are able to do this specifically because a specification is provided for how the system must look to the outside world. A Symbolics server could be written in LISP; a DOD special hardware server in ADA. A cheap, superfast Xterm server in assembler. > >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? I mentioned that Open Look certified toolkits have to conform to the Open Look style guide which does not depend on a specific implementation. > >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 That's exactly what we're hoping for :-) > 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. Should we duplicate all the bugs also :-( Your point about fully supporting the style guide is a bit sticky though. It appears that the style guide changes to match Motif releases rather than staying somewhat constant. From 1.0 to 1.1, scrollbars have additional functionality, file dialog boxes look different, etc. Furthermore, the style guide has been bent to match the bugs in the implementation. Rather than having a style guide which says "this is how it should work" and a list of bugs in the current implementation, the style guide sometimes says things like "You can's set the focus frame on this kind of object". If you try it, the reason is obvious -- it's not that it doesn't make sense, it's that the widget trys to do it but has some bugs in it. Wouldn't it make more sense to say "This is what we are aiming for", so people can expect some sort of consistent interface, and admit to some bugs which you are committed to fixing; instead of creating this incredibly obtuse set of inconsistent objects and trying to write a spec to match it? -- Tom LaStrange toml@Solbourne.COM