ProWesS Introduction

  1. What is ProWesS
  2. This manual
  3. Installation
  4. The downside

What is ProWesS ?

ProWesS is short for PROGS Windowing System, it is a new window manager, which was designed with a few specific goals in mind :

This manual

This manual is intended to explain in detail what ProWesS is about, how it operates, how it should be used and how it can be extended. For some specific details like possible errors of the access routines, we would like to refer to the ProWesS_ddf DATAdesign file.

While writing this manual, we often use terms which are not explained until later. It is always a problem to explain something with no or little background knowledge. So if you come accross an unknown term, just read on and everything should become clear later.

There is a separate chapter which contains some example programs. That chapter is written to be read at any time during the exploration of ProWesS. The impatient reader could immediately start there.

The chapter about adding your own types to ProWesS is not for the faint-hearted. That part needs more self-study, it doesn't contain any examples, just the theory. A lot of guidance should however be found in the sources of the standard types. When starting with ProWesS, you should skip that part.

All things considered, ProWesS should not be too difficult to master. We expect that writing programs which use ProWesS should be possible after reading the manual twice. In any case, if you have any problems with all this, do not hesitate to contact us.

We (and everybody who uses these manuals) would like it very much if you could send us any comments about this manual, such as

The bottom of each page mentions when the HTML document was last modified. I will try to keep this date correct, however it is only meant to indicate changes in the information provided, I will not change that date when correcting spelling mistakes or HTML errors.

Installation

ProWesS is a job which makes itself available to clients in the form of a Dynamic Link Library (a thing with an efficient access method).

Some extensions have to be loaded for ProWesS to run : the dynamic link library manager, syslib, PROforma, the pointer interface and the thing system (usually part of Hotkey System II). It is also best to have the "Button Frame" loaded for sleep to work as expected.

ProWesS has the shape of a job, and loads its configuration file ("ProWesS_cfg") when it starts. A parameter can be given to ProWesS to specify the path where the configuration file can be found (e.g. "win1_pw;flp1" to search on "win1_pw_" and "flp1_" in that order). If no parameter is given or the configuration file is still not found, then first the program default and then the data default devices will be searched.

The fact that ProWesS is a job (and not a resident extension like most libraries such as the Menu Extensions), has certain advantages. Jobs can always be loaded (if you have enough memory), and jobs can always be removed. When loading a job it is possible to pass a parameter (like where to find the configuration file), which is particularly useful. Also, no memory is wasted if ProWesS is loaded while a copy was already running. So if you want to release the memory which is used by ProWesS, you can just remove the job. Of course the disadvantage of this scheme is that you can accidentally remove the ProWesS job, which is dangerous as all programs which use ProWesS will also be removed, so you could loose data that way (in fact, if you were to remove PROforma, then ProWesS and all jobs using either will also be removed).

The downside

ProWesS is a complex system. It is designed to be easy and fast. However things can go wrong in some situations, so you should watch out for the following points. These things could make ProWesS go wrong completely.

An example is creating an object in a system, which is positioned in another system. This could cause major problems. You should also never use objects after they have been removed, and you should be careful when removing objects that all links to that object are also removed (e.g. removing the owner of a keypress without action, removing an object which can be navigated to in an edline).

Another typical thing which can go wrong are taglists. They are not checked by the c compiler and therefore wou are not warned when things go wrong. When passing invalid tags, just an error will be produced, but you have to be careful about using the correct number of parameters for each tag, and always ending taglists with a NULL.

Fortunately, these problems can be avoided, and a program which is fully tested should always run safely. The main possible problems for properly debugged programs are types which are not available and running out of memory.


PROGS, Professional & Graphical Software
last edited February 7, 1996