pwh@bradley2.bradley.edu (Pete Hartman) (12/20/90)
The new release of SunOS appears to come with OpenLook by default. We already have X installed (albeit it could maybe use a rebuild now that I'm starting to get the hang of it). My understanding is that there is some overlap in the libraries. What are some general opinions as to whether I should keep the Sun supplied (OpenLook) libraries in preference to the X built ones or vice versa? I did find with another system running OpenLook (V1.0) that many X applications didn't have all the Widgets and such that they expected. Are the Widget Libraries and other toolkits the only things from X I'll need to keep? -- ----- Pete Hartman pwh@bradley.bradley.edu Haazavaa?
brsmith@cs.umn.edu (Brian R. Smith) (12/21/90)
In <1990Dec20.145211.3999@bradley2.bradley.edu> pwh@bradley2.bradley.edu (Pete Hartman) writes: >The new release of SunOS appears to come with OpenLook by default. >We already have X installed (albeit it could maybe use a rebuild >now that I'm starting to get the hang of it). My understanding is >that there is some overlap in the libraries. >What are some general opinions as to whether I should keep the Sun >supplied (OpenLook) libraries in preference to the X built ones or >vice versa? I did find with another system running OpenLook (V1.0) >that many X applications didn't have all the Widgets and such that >they expected. Are the Widget Libraries and other toolkits the only >things from X I'll need to keep? The OpenWindows X binaries (OpenLook is a user-interface specification, not a software package) are supposedly compiled directly from the standard MIT X source. So, in any cases of overlap, YOUR versions will be more up to date (fewer bugs), and functionally equivalent. So, if you're willing to trust *my* advice, chuck the OpenWindows libraries that you already have compiled, like libX11, libXext, and libXau. (Or be cautious and save them somewhere first, and see if the OpenWindows goodies run with the MIT ones.) -- Brian brsmith@cs.umn.edu
guy@auspex.auspex.com (Guy Harris) (01/05/91)
>The OpenWindows X binaries (OpenLook is a user-interface >specification, not a software package) are supposedly compiled >directly from the standard MIT X source. So, in any cases of overlap, >YOUR versions will be more up to date (fewer bugs), and functionally >equivalent. They aren't all compiled from the MIT X source, and if you use the MIT source your versions of the libraries that aren't will not be functionally equivalent. According to a "comp.windows.x" posting from Rick Heli at Sun, the OW 2.0 version of "-lX11" has the following features added: - compose character processing in XLookupString - DNI support - code to retry failing socket connections on start-up You might not care about them, but there may be some who do.... I think other vendors have added compose support in XLookupString as well. It would be Really Nice if X11R5 included it; I don't know if it could be done in a way that's compatible with the way any or all of those vendors have done it or not. (It would also be Really Nice if X11R5 could support the Num Lock and Alt Graph keys on the Sun Type 4 keyboard and other keyboards, as long as we're talking wishlist; yes, I sent this to the MIT folks when they put out the message asking about X11R5 wishes.) Another posting from Rick Heli indicated that there are also keysyms for various "dead keys" in <X11/Sunkeysym.h> in OW 2.0, and that they "have now been registed with the Consortium and will in the future appear in XKeysymDB". I don't know if the OW 2.0 "-lX11" is up to the latest patch level of the MIT source or not. In another "comp.windows.x" posting, Larry Cable of Sun indicated that the "-lXt" in OW 2.0 is "'vanilla' X11R4 up to and including fix-13", but that the patch that corrected the revision number of the Intrinsics "arrived too late for inclusion into the product", so if you use a widget library built with the MIT include files you may get the "Widget class blahblahblah version mismatch" complaints if you use the OW "-lXt" library. I haven't seen anything about the other libraries. Of course, if you can get the OW source (which has been claimed to be available, albeit at a non-negligible medium charge to at least some customers, and without the right to arbitrarily redistribute it - I forget whether you have to be an S5R4 or SPARC licensee to get the source, or just to redistribute binaries based on it with a licensing fee; this topic has been flamed to death here and elsewhere), you could merge in any MIT or other fixes and install that version.