david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (04/10/90)
>rick@hanauma.UUCP (Richard Ottolini) writes: >>At least XView has a fighting chance now due to its >>relative "openness". and I responded: >No toolkit which is not based on Xrm has a fighting chance. Some people were not sure what I meant by this statement. My assertion is this: XView not only ignores the Xt toolkit, but also bucks the trend by ignoring the Xrm resource manager. Heather's comment to me was "That's an unqualified potshot... FYI: XView does use X11 resources and xrm." Heather is correct in a technical sense: there are several places where information is obtained from the Xrm database. However, it important to note that a significant difference in philosophy exists between how Xt and XView make use of resources. Specifically, resources are an integral part of the object concept of the Xt toolkit, whereas they are optional features inconsistently and rarely used by the XView toolkit. For example, using any of the Xt widget sets, one can specify fonts, colors, translations, and the like for individual components of the interface from resource files. This flexibility and addressibility allows such tools as the WsXc "widget interface interpreter" recently posted by Martin Brunecky. The limited use of the Xrm resource database, and the lack of addressibility is seen as an advantage by some people within Sun. Specifically, they feel that a consistent look and feel can be maintained in this way, whereas the Xt approach promotes chaos. If anybody want my long analysis of the limited use XView makes of the Xrm database, send me mail, and you'll get all 466 lines of it. ---------------------------------------------------------- David Smyth david@jpl-devvax.jpl.nasa.gov Senior Software Engineer, seismo!cit-vax!jpl-devvax!david X and Object Guru. (818)354-6344 JPL, M/S 301-260, 4800 Oak Grove Drive, Pasadena, CA 91109 ----------------------------------------------------------
hvr@kimba.Sun.COM (Heather Rose) (04/14/90)
In article <7713@jpl-devvax.JPL.NASA.GOV> david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) writes: > >Some people were not sure what I meant by this statement. My assertion >is this: XView not only ignores the Xt toolkit, but also bucks the >trend by ignoring the Xrm resource manager. > >However, it important >to note that a significant difference in philosophy exists between how >Xt and XView make use of resources. Specifically, resources are an >integral part of the object concept of the Xt toolkit, whereas they are >optional features inconsistently and rarely used by the XView toolkit. The key difference between the philosophies of XView and Xt is this: Xt is meant to be a general purpose intrinsics platform for building a wide variety of user interface toolkits. XView is meant to be an OPEN LOOK user interface toolkit. While Xt provides mechanism and very little policy, XView provides policy which is defined by the OPEN LOOK spec. XView is not as consistent as it should be with resources. We've cleaned up some of these things in the next release. However, how XView makes use of xrm is really not the issue here. The issue is how easy is it for the end user to make their user interface choices? Sun does not think it's reasonable to expect each end user to become X and Object Gurus just to make choices in the environment. It is the toolkit's and the environment's responsibility to provide ease of use tools to allow end users to make easy choices for customization. For example, Suntools offered the program, defaultsedit. Very rarely did Suntools users touch their .defaults file. If we would say to the customer, "you have to modify this widget name and search around to find out what the accepted values are. Oh and let me explain the difference between an instance and a class," they'd just look at us like we were crazy. It is my opinion that Sun users are not significantly different than users of other similar systems. I had the privilege of training a secretary on the Suntools platform. I showed him how to change his environment and use the programs. It is a very eye-opening experience to explain things you take for granted to someone very foreign to the system. It was surprising to me how something such as defaultsedit can be seen as so complex by someone else. The user interface specification, OPEN LOOK, defines that all applications should have a property sheet which will present customizable issues to the end user graphically. The problem with XView is that it does not make it easier for the application programmer to define property sheets. The problem is also that few of the general toolkit options are presented on the desktop property sheet. While XView is addressing a certain class of resource issues which use xrm to solve, it will not be as flexible as Xt since it needs to remain an OPEN LOOK toolkit. One of the advantages of having a strong policy is that the end user can use a large number of applications and expect consistent behavior from all of them no matter which vendor releases the application. For example, the Byte article that went by a while ago mentioned that the Mac toolkit was the GUI with the most consistent look and feel among applications. I have read other stats that say Mac users know an average of 12 applications while users of other similar systems only know 3 applications. The learning curve goes down for the next application when the user can apply experience learned from previous ones. This kind of consistent behavior is what OPEN LOOK describes and what XView implements. No matter what toolkit is used to implement an application, if it is an OPEN LOOK application using an OPEN LOOK toolkit, the end user should not be able to detect the underlying mechanism. No surprises means greater success using the environment. _________________________________________________________________________ Heather Rose, Window Systems Group, Sun Microsystems, Inc., hrose@sun.com Perhaps your XView question has been answered before. Find out by sending e-mail to xvstuff@kimba.eng.sun.com with Subject "help".