2. Introducing Windows to Unix: User Expectations

Colin Prosser

2.1 INTRODUCTION

This talk is aimed at giving a general overview of the main issues to do with window managers without going into details. My position paper (see Chapter 10) raises many other issues, but my view was that these are probably best discussed in the Working Groups.

The focus is on introducing windows to Unix environments because of the interest of the Alvey Programme in the problem of window managers under Unix systems. Considering windowing in Unix systems does, however, force a wider context on wind owing issues, and other or future operating systems should not be forgotten.

2.2 USER EXPECTATIONS

When introducing windows to Unix environments we are trying to provide the user with good facilities. What will the user expect? Considering windowing in Unix systems from this point of view, five key expectations may be discerned:

1. Compatibility. The benefits of the windowing system should apply to existing (not just new) applications. The windowing system must provide an environment in which existing applications and commands continue to work unchanged. But it must do more than just that; it must also provide the means for enhancing those programs. There seem to be two methods of doing this. One way is through a better shell facility where a graphical interface provides general-purpose text-oriented command manipulation. Another way is to take an existing command or application and build a specialized graphical interface around it. The former approach is being investigated at RAL. The latter approach has been applied successfully, for example, by Office Workstations Limited who have produced a graphically oriented higher level debugger (called hld) based around sdb running on PNX.
2. Intercommunication. Windows enable several separate contexts to be presented in one overall context. It seems natural to allow operations to apply across the separate contexts as well as within contexts. This leads to the idea of being able to select from the output of an application running in one window and to supply this as input to an application running in another window. This concept is often called cut and paste between windows. A simple example might be to run 'Is' to obtain a directory listing in one window and to use this output to provide a filename as input to a program running in a different window. On systems known to the author, this sort of operation can only be applied to limited kinds of objects and frequently only to text.
3. Portability. There is an expectation of software portability among Unix systems. Similar considerations apply to applications using windowing facilities. How are we to achieve portability? We have to look at the problem in terms of variants of the same system as well as in terms of quite different systems. The SPY editor (see section 3.3.1) was quite difficult to port to different Unix systems. Why? What makes it easy, generally, to port things between versions of Unix systems? A standard programming interface is important in resolving this difficulty. We must tackle the issue of standards for windowing systems. Can we take GKS [28] as a basis for building or should we start again? There will be problems if we try to address too large a goal - look at CORE [24]. So should we go for a minimal system? These are some of the alternatives to be considered.
4. Distributed Systems. With networks of (possibly mixed) systems, use of windowing systems should apply elegantly network-wide. With networks, such as the Newcastle Connection on PERQs, we are confronted with a whole new set of problems. For example, PERQ PNX uses a window special file to associate a name in the filestore with a window, and the Newcastle Connection allows transparent access over the network. However, if you try to archive a window special file on a PERQ using a VAX archiver over the network, it may not work quite as expected if the VAX archiving system does not have any knowledge of that type of special file. We must account for applications not knowing about windows. As another example, what should happen if I perform a remote login from a PERQ to a SUN? What does it mean? What window system applies to that login session: the one on the PERQ or the one on the SUN? Issues such as these have yet to be tackled.
5. Graphical Toolkit. The programmer needs tools to assist effective exploitation of windowing capabilities, both to create new applications and to modify existing software. The notion of tools includes examples to follow which provide guidelines for good design. What graphical primitives should the system support in libraries and as system calls to provide a graphical toolkit? To give an idea of the richness of the toolkit I am contemplating, I would consider that most existing windowing packages for Unix systems, including PERQ PNX, are, at present, relatively bare of tools. That is not to say that high quality applications cannot be built with today's windowing systems. However, experience shows that it can take considerable effort. It would be difficult for the unskilled user to write, for example, SPY without any assistance. What is a graphical toolkit and what support is required from the operating system? What guidelines can we provide to encourage good design?

2.3 DISCUSSION

Chairman - Bob Hopgood

Rosenthal:

On point (2), there are two systems on the SUN next door that allow this: SunWindows and Andrew.

Prosser:

I would be interested to see what you have done.

Hopgood:

They should be more general than that. What does it mean to pass a picture to a text processing program?

Williams:

Or worse still, spreadsheets with complete expressions. Are we moving the bitmap or the representation of the expressions?

Hopgood:

There is a whole problem in specifying what you are passing.

Prosser:

We could pass structured display files with type tags, but we must extend the model of window management defined in Tony Williams' paper (see Chapter 3) as it does not cope with it at the moment.

Hopgood:

Was your reference to GKS in point (3) meant to be provocative?

Prosser:

If you like. GKS just does not address window management problems.

Rosenthal:

On point (4), we have done this on our system. It allows uniform access to all windows on our 4.2. We have even tried running it over SNA.

Prosser:

You have assumed an application program interface and a network standard that the other system must support also. Can we agree on it? There are many different solutions. Yours is one, but is it for everyone? There are many people who would prefer a solution within an ISO standards context.

Rosenthal:

Anything with an 8-bit byte stream is enough.

Teitelman:

Also missing from the list is the graceful migration between applications written for displays with varying resolutions and from colour to black and white. That is an issue: device independence.

Myers:

I am disturbed that there is no one here to represent other than the general purpose window manager interface we all know, namely a specific interface like the Macintosh. Its user interface is set.

Teitelman:

A general purpose window manager should allow you to emulate the Macintosh, or have good reason why not.

Prosser:

You still land up with conflicts for somebody who has a context editor for his work, Macintosh-style, and some other applications bought in from different companies using a different user interface.

Rosenthal:

The big Macintosh book lists all the routines you can call and tells you what they will look like on the screen. It is difficult to see how you can take these routines and produce a different interface. You could provide a virtual Macintosh with a window or some other system but to provide the set of routines to do something different would be difficult.

Another issue is that standards take too long to produce. A de facto standard window manager which is freely distributed and widely used may be the only way to achieve consensus on the interfaces and capabilities of window managers.

Bono:

I also do not see any user expectations about performance issues in the list. When building a product there must be performance requirements. Is there nothing we can say, or do people have an implicit model: "as fast as possible"? We should talk a little about performance.

Williams:

Some feedback techniques do not work if the window manager's performance is too slow. Some machines do not move bits fast enough.

Bono:

There are also size performance issues, as on small machines. There are tradeoffs between precalculation for a faster user interface versus keeping raw data. There is a lot of practical experience that needs to be documented.

Prosser:

Yes, I think performance is important to get slick user interfaces, but we cannot enforce them on everyone. There are cost tradeoffs when building a machine. Some people can live with the degraded performance sometimes and therefore you may tailor your user interface in that direction.

Bono:

You are looking for a single answer. There may not be one. It is an issue. There is lots of experience in this room and we may be able to categorize things.

Myers:

There are representatives of 60% of the world's window managers here and they have virtually identical appearance. Their differences are listable. Is this because they are based on two systems from PARC or because there are, say, only seven ways to write a window manager?

Hopgood:

They all look different to me, although I agree they all have square things on the screen!

Rosenthal:

They are all the same. The difference in application programming level between a tiling and an overlapping window manager is very small.