price@WSL.DEC.COM (09/08/88)
Here is some information regarding DECwindows specifically.
DECwindows is an ongoing program at Digital to develop systems and applications
across our strategic operating environments (Ultrix, VMS, MS-DOS and in the
not too distant future, OS/2) which share a common human interface. As
much as is technically possible, the application programmer will
see a common API.
While many of the component products of DECwindows are still to be announced,
we have announced XUI, which is basically the common API for DECwindows
applications.
XUI includes:
1. The DECwindows Style Guide.
2. The DECwindows Widget Set (Xt Intrinsics based implementation of
the Style Guide).
3. Simplified programming interface to the widgets in addition to the
standard Xt style interface.
4. Tools for separating 'form' from 'function' via a User Interface
Language, a "Resource Manager", and a User Interface Language
'Compiler'. These tools are also used to internationalize applications.
5. The DECwindows Window Manager (ICCCM compliant overlapping window manager,
DECwindows Style Guide conformant).
6. The DECwindows Session Manager. An application which 'manages' the
user's session, including login/logout, screen lock, host access control,
application execution, and session attribute control (mouse acceleration,
screen/pointer/window color control, keyclick volume, pointer shape, etc).
5. Documentation.
XUI is available now on Digital's Ultrix platform. It will be available
soon on VMS. It is licensable in SOURCE FORM (all items listed above) for
porting to other platforms. This is the package that has been submitted
to OSF in response to the OSF RFT. The software will be supported by Digital.
The XUI licensing details are still being worked out, but it will basically
amount to a media charge for software vendors who wish to use the system
for their specific application product (no royalty charge, unlimited copying
allowed). For hardware platform vendors, the terms are still under review.
There will likely be a small royalty charge per copy to hardware vendors.
Again, this is still being worked.
To answer some of Ken Lee's specific questions:
Architectural Differences:
Toolkit (XUI)
-------------
Assuming Open Look for X is built using the Xt Intrinsics, both systems
will be architecturally the same. At least, one should be able to mix and
match widgets from both systems in an application. But until Open Look
is actually *implemented*, we will not know for sure.
Window Manager
--------------
Ours is ICCCM conformant, and I assume theirs will be too. Ours will conform
to our Style Guide.
Applications
------------
The DECwindows program has been in progress for 2 years, and currently consumes
1/4 of Digital's *entire* engineering staff. Needless to say, we have a
significant suite of applications in the wings. (At one time I counted
*50* separate projects underway). Announcements of specific products will
be ongoing. Stay tuned. All applications will be DECwindows Style Guide
conformant. In addition, we have been working with our third party
software vendors to integrate DECwindows into their products since December
1987.
Communications
--------------
We conform to the ICCCM. In addition, DECwindows utilizes a new Compound
Document Architecture, based upon ANSI standards in that area (I'm speaking
a bit beyond my own expertise now). This is a document architecture designed
to handle such things as integrated voice, moving video, and text in one
document.
Toolkit Contents
The XUI toolkit implements the complete DECwindows Style Guide. This includes
pulldown, pullright, and pop-up style menus, buttons, dialogs, scroll bars,
scale bars, radio buttons, toggles, etc., etc.
The Style Guide is available now from Digital. Contact your Sales Rep.
>ICCCM?
Yes.
>Window Grouping?
The window manager handles the grouping of multiple top level windows
within a single application. It will not provide the ability to arbitrarily
group applications in the first release.
>Colormap handling?
Yes. Also some support for color specification via the Session Manager.
Regarding another person's comments re: Digital adopting the OpenLook
Style Guide: Digital has been defining, implementing, and refining
the DECwindows Style since January 1987. We have been actively developing
applications which use the Style Guide and feeding back that experience
into the Guide. It would be silly to dump it now, to adopt an untested,
unimplemented style just because that style is arbitrarily named "Open".
It is no more or less "Open" than DECwindows. By the same token, the OpenLook
team should seriously consider adopting the DECwindows style. It works, and
source code is licensable and will be available very soon.
BTW, we will track the OSF decision.
-chuck
% flames >/dev/nullstpeters@dawn.steinmetz (09/13/88)
In article <8809080026.AA04531@eros.pa.dec.com> price@WSL.DEC.COM writes: > >While many of the component products of DECwindows are still to be announced, >we have announced XUI, which is basically the common API for DECwindows >applications. >.... >This is the package that has been submitted >to OSF in response to the OSF RFT. >... >The DECwindows program has been in progress for 2 years, and currently consumes >1/4 of Digital's *entire* engineering staff. Needless to say, we have a >significant suite of applications in the wings. (At one time I counted >*50* separate projects underway). In other words, DEC proposes a standard on which DEC has a 2-year head start, a standard developed in secret with no input from other vendors. Chuck, remember how evil this sort of thing was when you thought it was what Sun/AT&T had in mind ? How ironic that you're trying to use OSF as a vehicle for it now. ../dick -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
price@WSL.DEC.COM (09/14/88)
Dick St. Peters writes: > In other words, DEC proposes a standard on which DEC has a 2-year head > start, a standard developed in secret with no input from other vendors. > > Chuck, remember how evil this sort of thing was when you thought it > was what Sun/AT&T had in mind ? How ironic that you're trying to use > OSF as a vehicle for it now. Well, gee whiz, Dick, I guess we shouldn't allow the industry to share in work that has been ongoing at DEC long before this standards war started. I think it is rather noble of DEC to offer valuable code (it cost us a lot to generate this system) to an independent body (OSF), so that the entire industry can share it in the future in a vendor neutral fashion. (And note that the key word is *offer*. OSF is not required to select it). It was noble of IBM to offer AIX. And noble of the other vendors to offer their technology. AT&T/Sun chose to keep their technology proprietary, and to merely offer license on *their* terms. They refuse to play in a vendor neutral world. Yes, we developed the code internally as a DEC product, and we adhered to all our standard DEC policies regarding external disclosure. However, we have made review copies of the spec available for some time (as early as December 1987). When it became clear that OSF would be requiring a user interface system, we immediately worked to develop our XUI licensing strategy, and to more publicly discuss the DECwindows style. Until that time, we followed standard product procedure. We didn't know until then that we would or could be publicly offering it as an industry standard. We have no crystal balls here. The whole point of OSF is that the resulting system they develop is vendor neutral. We cannot force them to adopt the DECwindows interface completely as we specify, or at all. If they choose to change it to suit their purposes, we will offer the OSF compliant interface along with the other OSF supporters. When we offer the code to OSF, we are providing them engineering leverage so that they can provide the industry a standard, vendor neutral system in a timely fashion. Alternatively, OSF could start from scratch. I just don't see how that is to your advantage. I guess the bottom line is that in this particular case, Digital may get a head start if its interface is selected. One might view the advantage a particular vendor gets by having an interface it developed accepted by OSF a deficiency in the OSF RFT process. On the other hand, since that vendor will have also made significant investment in developing the selected item, one might cosider this a reasonable motivator for submitting technology. One could argue that the long term benefits to the industry at large far outweigh the short term advantage which might be had by a particular RFT provider. IBM will have a lead in AIX. We still think we can beat 'em. Sun had a lead in NFS. So now we have almost caught up with them. Everyone gets point advantages periodically. We could establish a rule that no one ships till every other vendor is ready. Who would benefit from that? Not you. Not us. Nobody. The very fact that OSF offered an RFT to which *anyone* could respond (including AT&T/Sun with Open Look - they aren't part of OSF at all) in my mind is *much* better than the "mine mine all mine" approach of the AT&T/Sun alliance. Did you get any say in the design of Open Look? By offering XUI to OSF, we are giving the industry input into the system in a vendor neutral, realistic manner. -chuck ps: This is an X conference. I believe we are rapidly diverging from the conference purposes, although as you know I am always willing to discuss this "off-conference".
thoeber@SUN.COM (Tony Hoeber) (09/24/88)
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