Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!ncsuvx!gatech!bloom-beacon!SUN.COM!thoeber From: thoeber@SUN.COM (Tony Hoeber) Newsgroups: comp.windows.x Subject: Re: Open Look vs. DECwindows Message-ID: <8809232303.AA16485@coral.sun.com> Date: 23 Sep 88 23:03:31 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 96 This is in response to Gary Aitken's message of September 1... Gary, Thanks for taking the time to review the spec, and focusing on implementation issues. Such feedback is very useful to us. We're committed to having OPEN LOOK be implemented on X toolkits. In fact, today there are two OPEN LOOK X toolkits up and running -- XT+ from AT&T, and View2 from Sun. The OPEN LOOK designers are working closely with both of these groups to ensure that the toolkit implementations and the OPEN LOOK spec stay in synch. Here are brief responses to your comments... The current specification makes heavy use of bitmaps or drawing functions for object outlines, including "application window" and icon objects. I.e. windows and icons, among others, are not square -- they have rounded corners. The result is that a proper implementation requires windows with a zero border width, an interior large enough to accompany a painted pseudo border, and a client side procedure for painting the border. The client may also require some means of distinguishing between events registered on the border and the interior, requiring an overlapping window as well (and the corners then might not match up quite right). In the July 15 revision menus and icons (but not windows) had round corners. These have been changed to the familiar square corners. The specification includes objects (such as sliders) which have no background. The objects are irregularly shaped. The spec says events will fall through to the main window background. This means a proper implementation must create multiple X windows for an object, which are not parented to a single X window for the object as a whole. Doing geometry configurations on something like this is a nightmare, since you can't simply move the main X window for the object. The spec never meant to imply that controls such as sliders needed to clip to their irregular borders. It's fine for the slider to take all events within its enclosing rectangle. The spec practically requires that window manager functionality be buried in the application. It allows the application to modify the iconify/move/... menu associated with the window manager frame. Presumeably, two separate applications could modify the window menu to contain the same name with a different functionality... The spec must have been misleading on this. The intent is *not* to allow the application to modify the window menu. The window menu changes only to reflect a few known states: -- The Zoom/Unzoom and Open/Close buttons reflect current state of the base window. -- Any inactive buttons are dimmed (e.g. the Properties button if the application has no properties.) -- The Dismiss/Cancel button on property sheets reads "Dismiss" if there are no pending changes, "Cancel" if there are pending changes. The spec requires variable width fonts (i.e. all button text is supposed to be painted in variable width font). Right -- for the standard elements of the user interface (titles, button labels, messages in the footer, etc.) The spec says nothing about what fonts the application uses in its display areas. The help display requires clipping to a circular object. All it requires is clipping the image in a circle around the mouse pointer. The help lense is displayed against the help window background, not against the desktop background, so no arbitrary clipping capability is called for. There is currently not an X implementation, so nobody knows about the inter-client communications or toolkits. As I mentioned above, there are two X implementations running today -- XT+ from AT&T and View2 from Sun. As for the spec (which intentionally describes the user interface per-se, not particular implementations) it has been reviewed by the author of the ICCCM, David Rosenthal. The window manager is supposed to have the ability to deal with root level objects in groups (e.g. select a bunch of windows and icons and move them together). Right, this is a feature of the ICCCM. The window manager is supposed to maintain color maps, and allows users to change the colormaps for individual windows. No, I don't think so. The spec is compatible here with the rules for color maps in the ICCCM. The idea is that each application has its own property sheet with a control that allows the user to set the background color for the windows belonging to that application. The global property window (not the window manager) allows the user to set the default window background color for when applications initially start up. Thanks again for your comments. Tony Hoeber