Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!sun!kimba!hvr
From: hvr@kimba.Sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: Re: Xw on Sparc? Xaw vs Xw vs XView? Interp layout contraints?
Message-ID: <133140@sun.Eng.Sun.COM>
Date: 20 Mar 90 03:16:41 GMT
References: <6873.25ff8b27@swift.cs.tcd.ie> <3044@bacchus.dec.com>
Sender: news@sun.Eng.Sun.COM
Reply-To: hvr@sun.UUCP (Heather Rose)
Organization: Sun Microsystems, Mountain View
Lines: 126

In article <3044@bacchus.dec.com> klee@decwrl.dec.com writes:
>In article <6873.25ff8b27@swift.cs.tcd.ie>, jorice@swift.cs.tcd.ie writes:
>
>> (4) On the subject of XView, how is it to program? 
>
>The semantics of XView are similar to those of the X Toolkit.  There
>are some advantages to XView, such as more UNIX-specific support.
>Disadvantages of XView are incompatibility with X Toolkit widgets, no
>subclassing, no separation between "intrinsics" and "widgets", and no
>support for popular X Toolkit user interfaces such as configuration
>through translation management and resource management.  Also, some
>customers are now requiring (to some degree) their purchases to be
>based on the X Toolkit (e.g., the recent U.S. Government FIPS).

It's encouraging to see Digital has taken such an interest in XView.

First, XView has semantics similar to SunView which predates the X
Toolkit.  Both Xt and SunView are based upon some research done in 
the late 1970's.  The net result of differences between Xt Intrinsics 
and XView intrinsics is very close; however, the chosen implementations 
of those semantics differ in substantial ways.  Sun seriously considered
moving XView to Xt Intrinsics; however, too many problems as far as loss
of functionality and implementation details.

Second, what one considers advantages to XView depends on a person's needs
and past experience.  Here are some that we consider advantages:  more 
UNIX specific support, extensible (more easily than Xt if you look over
the tutorial slides on the subject), familiar API for SunView programmers,
source is free, potentially large platform base (Sun ships 1/3 of all 
workstations in the world), will be provided for IBM, DEC, and H-P 
platforms as well, supported by a vendor using it as primary applications 
delivery platform, spot help facility.

Third, if a Sun customer truly needs an Xt solution, we offer Xt+ with the
release this summer.  XView meets a different class of needs than Xt+ 
(e.g.  the quickest way to port from SunView to X11).  Also, extensibility 
in any toolkit is useful, but in many fewer cases than one would have 
you believe i.e. most toolkit users just want to get their work done 
without having to become toolkit or window system experts.  The ability 
to add a new class is useful for certain cases, so XView provides this 
functionality.  It's not fully documented yet, but we are addressing 
this point.  There's slides from a tutorial one can ftp from expo, or 
send the message, 

	send doc tutorial.extensions.ps
to
	xvstuff@kimba.eng.sun.com

Fourth, the statement about extensibility is false.  XView is extensible in
the same way Xt is extensible.  They both are extensible when the application
is compiled.  Neither Xt nor XView allow subclassing while the program is
running.  That's difficult to do in C.

Fifth, the statement about separation of intrinsics is also false.  XView has 
intrinsics, we've just never given them the publicity that Xt Intrinsics enjoy.
Most application programmers want to use some user-interface toolkit to
provide a useful set of objects, or better yet some GUIDE tool which
interfaces to the user interface toolkit.

The XView intrinsics are stable and mature.  The notifier library, a major 
portion of XView intrinsics, has been stable since the mid 1980's.  XView 
objects are as opaque as is possible from C, and has had the same basic 
functions to manipulate these objects for all releases (going on it's 
third release this summer).

Both Xt and XView provide a true object model, as close as one can get in
C with very similar methods for subclassing.  However, neither one 
incorporates the runtime object creation one has in say SmallTalk.

Sixth, configuration through translation management is not as complete
as that in Xt.  Certain packages implement some schemes (i.e. .textswrc
or .ttyswrc), but the concept is not included in the XView intrinsics.
This is a very good point for a request for enhancement (RFE) to add to
a future release.  Thanks for pointing that out.  

Seventh, XView does not provide a nice wrapper on the X11 resources
(yet); however, an application programmer can use the X11 resources as
much as they like.  XView does not prevent their use.  The ideas behind
user preferences are a different approach in OPEN LOOK.  OPEN LOOK
specifies that every application should have a property sheet to
present configuration options to the end user.  The application may
choose to implement the configuration options via the X11 resources or
a separate file, or another database which may apply to more than just the
window system. 

Also, OPEN LOOK specifies a much more consistent look and feel across
different applications to make life much easier on the end user.  The
objective of OPEN LOOK is to make UNIX as easy to use as a Mac, since
UNIX has not been available to the majority of computer users.  XView
incorporates many dynamically customizable things such as setting the
default menu choice with Control-SELECT, pinning menus, pinning popup
frames, and menus are either stay-up or not depending upon usage.

XView does lack a large set of toolkit defaults (for example, all scrollbars
should be on the left instead of the right, or all TTYSW should have this
font, foobar), but we're working on these issues.  The extent that Xt goes
to to define defaults is a bit of overkill, and would be a performance hit 
to add to XView. The current interfaces to resource changes in Xt based
toolkits requires that the end user know something about the implementation 
of the toolkit.  Sun does not think it's reasonable to expect all UNIX 
users to edit some bizarre dot file to specify these things.  The 
environment should present options to the end user in a very obvious way 
via property sheets.  The best way to add resources to XView would be an
automatic property sheet generator for a package.  Whether the properties
mechanism uses the X resource database is an implementation detail.  The
end user only cares about provided functionality.  The programmer cares
about ease of adding that functionality.

Given those last two points, I think it's fair to say XView is currently
less customizable than Xt.  However, it is something we can and most likely
will do something about in future releases within the guidelines provided
by OPEN LOOK.

Eighth, what the FIPS states is that for a hardware company to participate
in the bidding process for government contracts, they must include an Xt
based toolkit in their offering.  Sun will be supplying Xt+ as part of their
window offering just as we include Ada as part of our language offering. 
The government requirements specify many things, like one must
use the Ada programming language.  This has not stopped C from becoming 
the most widely used programming language.


__________________________________________________________________
Heather Rose
Window Systems Group                      internet:  hrose@sun.com
Sun Microsystems, Inc.                        uucp:  ...!sun!hrose