This report summarises the changes we can expect to see in the graphics i/o of the first release of PNX for the Perq 3. The information is gleaned from the ICL product specification which I seriously recommend that you do not read. A later version of this report will include further information about mouse input which has not yet been documented by ICL.
On the whole, the average user will see little difference in the functionality of the facilities available via the window manager or system calls. Indeed a compatibility library will be provided by ICL to allow continued use of the PNX 2 wdbyte, wrasop, wgread and ioctl calls, though the latter routine will have to be renamed wioct1. They reserve the right to withdraw the library later.
Although there is a lot of new stuff to do rasterops and handle fonts, you can still see the old PNX peeking through at the bottom layer. So, for example, windows are still simultaneously teletypes and graphic devices, and window descriptor files live on.
The most useful thing provided is a partially reconfigurable window manager.
The window manager the user sees is now called leo, to make it seem more cuddly. I suppose, or perhaps to convince you it has more teeth. It is separate to the system (kernel) support of windows, which presumably will be made available at the programming level at some time. It seems that after booting there will be a console window in which a user can login. He can then activate windows which will be supported by the kernel, but normally it is expected that he would start up leo and use it to create and manipulate windows. The default configuration presents (exactly?) the same user interface as PNX 2, but there are some new facilities:
We have, however, lost the open command which would create a new window according to some named window description file. This is possible instead through a shell command, see later.
Most usefully, at startup leo can be given a set of overriding descriptions of what you want each button to do, and what menus should be presented. You can set up your own:
These last two facilities are implemented by text files which consist of lines each having a text label and an action to take. The file describing the mouse buttons only has three lines, and the text label could be used to give labels for the buttons in a spy-like function box (or mousehole, as ICL love to call it) to be provided by leo. It seems a function box will not be implemented in the first release.
The actions available are formed from the keywords:
menu create promote
quit reshape demote
help grow pop
undo move attach
null delete
activate
Actions from the first column must be given alone. The menu keyword is followed by the name of the file that contains a description of the menu. (Hence, you may have a difference menu on each mouse button).
Actions from the second column may be combined with any of the keywords from the third column. Null is provided to allow combinations such as null pop. It is difficult, ICL points out with wry humour, to imagine any construct using delete other than null delete.
Activate is like create but even the size and position of the window come from the default window description. Pop does whichever of promote and demote is appropriate for an obscured or unobscured window. Attach attaches the keyboard to the window, making it the listener.
There does not seem to be any shell escape action that would allow real user extensibility. It is also not made clear whether graphical input is available to a window without it being selected, though a press and release will still be needed to get the window manager's popup menu. There is still no way to get leo to change directory whilst it is running, but it can always be done by programming your .profile appropriately.
In order to implement the who(1) command ICL have decided to have an extra sentry process for each window leo creates. This will be the parent of the window's shell and its sole function will be to remove the login entry for the window from /etc/wtmp when the window is closed and the shell in it dies. There must be an easier way.
The window manager will be locked in core for improved performance (of it alone. presumably).
The old style window descriptors are still with us, but they can now use a textual description. It would seem that window special files have gone out of the window, if you'll forgive the expression, so to replace the shell command:
cat fred >windescfile
which used to open a window automatically we have three new shell commands:
from windescfile >fred into <fred windescfile launch windescfile [command]
The first two commands open a window described in windescfile and read from or write to it, respectively. Instead of a window descriptor file you can specify a window number as -w 99. Launch opens a window as if you had created it with leo, does a full login, and runs the given command in it. [At last!]
The textual description of a window does not allow a cursor pattern or cursor mode to be specified. The former was never implemented in PNX 2, though it was defined. Presumably, binary window descriptors will not allow them either.
The main change here is the definition of a whole new set of slightly higher level structures to hold rasters, fonts and line definitions. These are so complex that you'll want to think twice before learning all about them. Some of the complexity comes from the provision of multiple plane rasters, so that colour [fanfare!] can be implemented. More complexity is due to everything having a poly version so that, for example, many lines may be drawn by one system call.
The principle advantage of the new structures is that window and memory bitmaps now have a more unified treatment. This probably means that you can rasterop directly between two windows now. A tiling rasterop routine is provided, and all the routines (including text and line drawing) take an optional mask bitmap and clip region. Rasters must now be multiples of 32 bits, instead of 64 bits wide, but there seems to be no reference to alignment, although the raster must start on a byte boundary, at least. The full range of 16 raster operations is provided, even for line drawing.
When operating with two multiple-plane rasters, only the planes at a common depth take part in the action. However. all the routines (including text and line) can specify instead a series of operations between individual planes. This could be used to collapse a multiplane raster to a single plane, for example.
Other changes mean that fonts can be shared between several processes, although it may be hard for this to be achieved by anything other than the window manager. They can be loaded into memory in the usual way, when they will not be shared, or they can be loaded into reserved character special files. The program is supposed to hunt through the list of file slots until it comes across an unused one, which it can then write into (?). A process wanting to share the font has to somehow know the name of the slot and open it for reading. Perhaps a library routine will be provided to hide this from the user.
Each character in a font now has a printing width that can differ from the bitwidth of the character in the raster, and there are 256 characters in a font! Printing can specify a range of characters that the source string must consist of. For example, a null terminated string has a range of 1 to 255. Proportional fonts can be printed with a fixed width: this has to be done character by character in PNX 2.
Lines can be given a repeating dot pattern, specified in a sequence of 32 bits. This can be made to restart at every vertex of a list of lines, or not. You can also specify whether the first or last point of a line is or is not to be drawn. The default is as on PNX 2 where the final point is not drawn. A width for lines can be specified too, but you may find the initial implementation restriction of 1 a bit limiting.
Finally, a filesystem representation of the various internal structures is defined, though we don't know what will use them.
Omitted from this version of the report are cursor patterns, and mouse input, pending further documentation from ICL. They make it clear that the initial release will not provide icons nor groups of windows.