22. Structures Task Group

22.1 REPORT

The Task Group membership was:

• Colin Prosser
• Dominic Sweetman
• Warren Teitelman

This Task Group arose mainly from the Architecture Working Group discussion and the joint session with the Application Program Interface Working Group. We thought it was a good idea to look below windows to see if there are more fundamental objects. We attempted to characterize the common structure properties among all the window systems of which we were aware. We will dodge the issue of overlapping versus tiling. There seem to be good reasons for both styles of use. We will concentrate on what is common between them.

We have to be careful with our terminology here: a conventional window is a Byte reader's idea of a window and is a box on the screen with a name stripe, a border, etc. that you can move about on the screen, change the size of, and so on. A conventional window is shown in Figure 22.1. Windows can also be unconventional as shown in Figure 22.2.

Figure 22.1 Conventional Window

Figure 22.2 Unconventional Window

We will not insist on the bits of a window being enclosed in a rectangular border. Fast non-rectangular operations will permit windows with non-rectangular shapes. We want to find a primitive subcomponent of windows to divide the architecture into manageable lumps. We have been through several names for these parts: pads, panes, canvases etc and Colin Prosser has convinced us that we should use a word which is appropriate in graphics terms, namely viewport. A viewport is an area of transparency on the display through which something can be seen.

So the conventional window example is made up of three visible viewports: the name stripe, the scroll bar and the main interaction area, as shown in Figure 22.3. The more complex unconventional window example consists of four viewports, as shown in Figure 22.4.

Figure 22.3 Viewports of a Conventional Window

Figure 22.4 Viewports of an Unconventional Window

Viewports are not necessarily limited to being rectangular either. RasterOp leads to rectangular images, ultimately there might be BlobOp graphics primitives leading to blobs . You may have viewports hanging outside a window although the user interface people might say this is bad taste.

Viewports are defined hierarchically with the positions of child viewports being defined relative to the parent viewport. Clipping of the child viewport is independent of the parent.

A window then consists of a family of viewports organized as a subtree. The viewports of a window will usually be contiguous and non-overlapping although this need not be the case. Windows can consist of viewports only in one family. The intention is that the family of viewports in a window are all at Z coordinate levels such that they are either all behind or all in front of another window. Interleaving of viewports from different windows is not allowed. Algorithms determine where input goes according to the viewports. Input control attributes are associated with viewports (echo, ignore mouse hits etc).

When you look through a viewport, you see an image, (the sea!) and we do not really have a satisfactory name for that.

A tentative model of what happens in a window system is shown in Figure 22.5.

Figure 22.5

Applications draw into viewports. Applications can draw into several viewports, and viewports for a single application can be in different windows. This enables support for icons either as independent windows in their own right, or as elements of a group (the family of windows concept) within a window, in the style of Sapphire. As the substructuring notion is recursive, icons (of either variety) might themselves be composed of subfamilies of viewports. Extending this idea, and recalling that viewports are not necessarily rectangular or constrained to lie within some boundary, it should become apparent that the structuring concept presented also covers items like rubber borders which dynamically echo the new position a window would take were it to be moved or have its size changed.

These ideas were discussed and it was felt that they provided the basis for a sound model for substructuring. However, we did not have time to consider in any depth how well the model would stand up to close analysis, and consequently, this presentation aims to propose the model in overview only. Substantially more work would need to be undertaken before we could be sure that we do indeed have a useful model of substructuring.

A layout manager (which is one component of the window manager) constructs windows out of viewports, moves windows around and constrains them to behave properly.

The viewport manager clips the images and handles overlapping. It also handles input devices, for example, mouse events are directed to whichever viewport the cursor is over.

We looked at the interface between the bottom of the application and the viewport manager. The application passes things we have called pictures or sources to the viewport manager. We are not entirely happy with what we have called them and need a name. These pictures may be bitmaps, display lists or PostScript programs, for example. The viewport manager clips pictures and presents them on the display. This level ought to be device independent but this will usually be too difficult to achieve - although it would be nice if it were.

22.2 DISCUSSION

Cook:

Where does the association of viewports into windows happen?

Sweetman:

It's mostly about holding their inputs together, so associations are set up by the layout manager. It builds a window out of its Lego bricks which are viewports and returns a handle to the application to permit it to write on the window. The dashed lines in the diagram of a window system show how the application talks to the layout manager.

Myers:

This is very much like the Sapphire implementation. However, there are problems with it as an application now has two separate things to talk to: the viewport manager and the layout manager. It's not obvious which one of them to call and some calls may have to be repeated to both of them. For example, displaying something in the title line requires a call to the layout manager. It is very difficult handling input, for example, changing the listener.

Sweetman:

The viewport manager decides where the input goes.

Myers:

We did that and it is difficult to handle. The layout manager also needs to know who the listener is so that it can draw borders, annotate titles etc.

Teitelman:

These are really problems still to be solved, rather than being insuperable.

Sweetman:

But we need to consider whether the problems are so bad that we want to coalesce the viewport and layout managers.

Teitelman:

The separate managers are a way of discussing things. Most applications will have a fixed relationship but we do not want to be restrictive unnecessarily.

Thimbleby:

As soon as there's an argument for two there exists an argument for n managers, for example, a font manager, a colour manager etc.

Sweetman:

That's possible. The layout manager is not privileged. It's just an application.

Coulouris

I don't see anything wrong with having other managers. If there is a resource, there should be a manager of it.

Sweetman:

The architecture is not committed to this setup, there is no reason why managers cannot proliferate.

Teitelman:

The viewport and layout managers need not be separate bits of software. The only reason for their separation is because of their different functions. Whether or not they are implemented as one module is in the category of implementation details.

Sweetman:

It's the same as sharing the application interface. The layout manager will make calls on the viewport manager that applications don't do.

Myers:

It works fine for output, but is a mess for input.

Sweetman:

That's probably true for anything.

Bono:

Does the viewport manager have a single coordinate space?

Sweetman:

There is some kind of unified coordinate space.

Bono:

This is different from yesterday where we decided that there were multiple coordinate spaces.

Sweetman:

The display lists passed to the viewport manager need to have a notion of size in the viewport. There is nothing to stop scaling first.

Bono:

There is an issue as to whether the viewport manager has to maintain multiple transformations.

Sweetman:

The viewport manager must have a consistent mapping of the panels on the display. The location of a viewport on a screen is determined recursively by following from parent to parent until the root is reached which is in a fixed position on the screen.

Hopgood:

Do viewports have special attributes not in windows or are they all the same?

Teitelman:

From a practical standpoint, name stripes might not be fully-fledged viewports.

Hopgood:

Do they have attributes?

Sweetman:

Yes, we don't want separate classes of viewport.

Prosser:

For example, you would turn off input in name stripes.

Bono:

The hierarchy is for positioning of viewports. Does it also imply some inheritance of attributes?

Sweetman:

That's for further study. There are other implications of the hierarchy, for example, deleting a parent deletes the children, unwanted input is passed on up the hierarchy etc.

Prosser:

You should also mention soft events.

Sweetman:

Yes. The interface allows you to inject events to the viewport manager as if they came from a soft device.