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