ph@concurrent.co.uk (Paul Hamilton) (02/23/90)
In a recent magazine article, it said that "AT&T Co has signed with Sparc- compatible workstation manufacturer, Solbourne Computer Inc, for distribution of Solbourne's graphical user interface development system, the Object Interface Library. This agreement includes Solbourne's X Window System based window manager. Current development versions of the Library support both Open Loop and OSF/Motif. Computer vendors and software houses can get the source code from AT&T's Unix Software Operation, who can then pass on binary versions for any system supporting X Window System" [PC Week Feb 6 1990] Two questions: 1) Does anyone have any info concerning the Object Interface Library? 2) Where is AT&T's Unix Software Operation? Thanks...
marbru@auto-trol.UUCP (Martin Brunecky) (02/25/90)
In article <981@sl10c.concurrent.co.uk> ph@concurrent.co.uk (Paul Hamilton,CSDD) writes: > >In a recent magazine article, it said that "AT&T Co has signed with Sparc- >compatible workstation manufacturer, Solbourne Computer Inc, for distribution >of Solbourne's graphical user interface development system, the Object >Interface Library. This agreement includes Solbourne's X Window System based >window manager. Current development versions of the Library support >both Open Loop and OSF/Motif. Computer vendors and software houses can get I expect Solbourne folks to respond, but let me express an independent (may be not fully qualified) opinion. 1) Supports both Open Look and Motif. Well .... I would say supports Open Look, which may be forced to LOOK LIKE Motif. In some areas (scrollbars for example), they could and did superb job and allow for a true switch. Some areas, however, such as Motif keyboard traversal, aren't there (and will be tough to impement, considering how tricky the current Motif implementation is). Some areas are no-way. For example, the basic window layout is different between Open Look and Motif, file selection boxes, message boxes are different (there's even a different approach to it). There is just a very definite limit of what you can do with a single toolkit. 2) OI does not (and can not) use X resource database. Neither it has anything like UIL (I am NOT a UIL pusher). Thus any customizing must be provided for by the application code. I consider this a step back. 3) OI is C++ only. May be an advantage - but I would like to see more native implementations of C++ with DEBUG support first. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
garya@garya.Solbourne.COM (Gary Aitken) (02/26/90)
> I would say supports Open Look, which may be forced to LOOK LIKE Motif Unfortunately, you are basing your judgement on a demo you saw which had roughly one man month invested in it, concentrating only on the look aspect. The Motif implementation, when completed, will support both look and feel. As you observed, the scrollbars already do this. I would differ with you on your opinion of the difficulty of implementing keyboard traversal. I guess the proof will be in the pudding, but we have more than one person here who would be willing to place some money on it. > ...the basic window layout is different between Open Look and Motif This is a real problem. From our investigations so far, the primary difficulty is that the Motif style guide for applications appears to be much more restrictive than OPENLOOK. There are certain classes of applications which cannot be written to conform to the Motif application style guide without a very awkward interface. For example, Motif specifies that you use a menu bar, which may only have pulldown menus on it, and no stand alone buttons, across the top of the main window. What if the application has basically a single button in its top level window (This is not a contrived example; it comes from a real application)? To conform to the style guide, you are forced to make a pulldown menu with a single entry in it. > file selection boxes, message boxes are different This is not such a difficult problem, solvable by the toolkit in a manner transparent to the application. I'm guessing you are thinking of an interface at too low a level, where you are only mapping elementary objects from one interface to the other, rather than treating "file selection" as an object unto itself. > OI does not (and can not) use X resource database. Wrong. OI can, and does, use the X resource database. The current implementation does not use the resource database for complete specifications for all objects the way Xt does, however. The reason it doesn't is that the toolkit allows dynamic reparenting, which poses some problems regarding resolving resource names. We are working on solutions to that problem and hope to have something in place by summer. Existing applications get all sorts of things from the resource database. The window manager gets its total configuration from resources. The debugger, mail and news readers, and other tools all get information from the resource database. > Neither it has anything like UIL. Thus any customizing must be provided > for by the application code. Wrong again. It is a one line call to generate a complete object tree, complete with hooks to callback routines. We have shipped at least one client program for months now which has no application code describing any of its objects except those which it needs to create dynamically due to changing conditions. The client can easily be configured with a prototyper, and was built that way. > OI is C++ only. Yes. All I can say is that anyone who would choose C over C++ after having used it has no concept of what object oriented programming really is, or the benefits to be gained. Yes, you can do object oriented programming in C. Unfortunately, C technology does not give you all the benefits. You cannot enforce data hiding. You cannot enforce strict type checking. Even with the best of intentions, people will make mistakes, and you will waste a lot of valuable engineering time chasing down those bugs. We chose not to implement a C interface (it is possible) deliberately, to encourage our users to move to C++. We have encountered no problems with this that I am aware of. Our os people, dedicated died in the wool C programmers, have managed to use C++ and OI with little effort. Same goes for graphics people, test people. Having said all that, there is one reason I can think of to use C -- if you are trying to write code to ship to the least common denominator system, and you don't want to have to worry about C++ capabilities being present or not. But then, as someone said at the X conference: "If you have a system which only supports 14 character file names, we consider it broken, and the solution to that is to get a system which is not broken." Maybe we should all code in FORTRAN or COBOL? The same arguments were used frequently years ago when C started gaining acceptance. > I would like to see more native implementations of C++ with DEBUG support > first. Me too. Although the tools available to us for C++ debugging are as good as those for C, and are better than most. We have full interactive debuggers which understand C++ classes and demangle the member names. -- Gary Aitken Solbourne Computer Inc. ARPA: garya@Solbourne.COM Longmont, CO UUCP: !{boulder,sun}!stan!garya
vp01@bunny.gte.com (Vincent Phuah) (02/26/90)
You can call AT&T at this toll free number: 1-800-828-UNIX It is the AT&T Unix Software Licensing number. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * Vincent Phuah * * Software Technologies Dept. * * GTE Laboratories Email: vphuah@gte.com * * 40 Sylvan Road Tel: (617) 466-4130 * * Waltham, MA 02254 * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
marbru@auto-trol.UUCP (Martin Brunecky) (02/27/90)
In article <1990Feb25.190607.13952@Solbourne.COM> garya@garya.Solbourne.COM (Gary Aitken) writes:
.... the text deleted ....
Thanx, Gary - I am glad I'v prompted you to provide very thorough
explanation of some OI features. I hope you don't take my less
knowledgable comments as an insult.
Just two minor comments:
1) I was referring to the CURRENT state of OI. I did NOT try to
say that this and that is impossible. I was responding
to a request for toolkits available TODAY. And as you admit,
there is still a lot to do in OI.
2) My comment about C++. I was NOT talking about C versus C++.
(no discussion there, besides C++ availablity ...).
There are many folks who want to use the user interface from
ADA or (yes, archaic but still widely used) FORTRAN.
And again, I am not saying that it is impossible to interface
to C++ from ADA or FORTRAN - it's just not quite easy.
--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Martin Brunecky marbru@auto-trol.COM
(303) 252-2499 {...}ncar!ico!auto-trol!marbru
Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404