Why WMAN2?

(Warning:This is quite a long posting!)

Recently someone asked why I insist most of my newer software needs Window Manager 2?

He went on to claim that it discriminates against users of a BBQL (black box QL) by forcing pointer environment onto everyone, and either version 2 of pointer environment or SMSQ/E at that. This could be a “death knell” (his words) for the BBQL.

Firstly, the QL has been around for over 30 years and I’m pretty sure that the good old BBQL isn’t going anywhere as long as spare parts like keyboard membranes continue to be available for it (having had to replace one of those myself in the last few days on my trusty, rusty 1985 QL).

Of the huge amount of software available for the QL, only a tiny minority is specifically written to take advantage of the wonderful facilities of modern QL compatibles and emulators. More software has been written for a QL without a mouse than a QL with a mouse, which is why I try, in my own little way, to redress the balance.

There was a time back in the 1980s and early 1990s that I could not understand the point (pun intended) of pointer environment. I bought QRAM, got nowhere with it, then later tried QPACs 1 and 2 and started to see the advantages.

Switching between programs became fast and easy with CTRL-C. It saved and restored the displays of programs automatically, so I didn’t have to remember which key was needed to redraw in each program. Was it F4? Was it F5? Was it Shift F5? Task switching was easy, making it easier to use multiple programs, and the system was forgiving enough that even many badly written older programs continued to work (I know, I wrote enough of those myself!)

I got to appreciate that a lot of programs written to use the pointer environment and window manager looked very similar and were operated in a very similar way – look at the little application programs supplied in the QPAC1 package – they all looked very alike.

System Palette example

The System Palette giving a similar appearance to all programs. This guy is running Launchpad, Q-Bar and Q-Dock same time – SAD!

Programming tools like Jochen Merz’s Menu Extension (Q-Menu) made it quite easy to write pointered programs in BASIC by supplying a range of the most commonly required menus pre-defined and ready to use. Such programs could even be compiled and made into stand-alone executables. The QL always allowed multi-tasking; the pointer environment just took it to a higher level.

As to the allegation that the pointer environment was “difficult to set up”, well, at its most basic, all you need is a short boot program to start the pointer environment automatically (uses device FLP1_ assuming you’re running it from floppy disk):

100 TK2_EXT : REMark this may not be needed on some systems
110 LRESPR FLP1_PTR_GEN  : REMark pointer interface
120 LRESPR FLP1_WMAN     : REMark window manager
130 LRESPR FLP1_HOT_REXT : REMark hotkey system
140 HOT_GO : REMark switch on hot keys

There are three parts ot the pointer environment and they should be installed in the order shown.

PTR_GEN is the pointer interface itself and is responsible for the on-screen pointer arrow, controlling it via either the cursor keys or a mouse. It also handles the save and restore of windows as you switch between programs.

WMAN is the Window Manager and is responsible for the appearance of program windows and menus, helping give a consistent look and feel to programs.

HOT_REXT is the hotkey system 2, responsible for those hotkeys you can define to do little jobs like starting and picking programs.

There are sometimes ambiguous terms such as Pointer Environment and Extended Environment. Strictly speaking, Pointer Environment is what you get when you just install PTR_GEN. The term Extended Environment strictly speaking refers to when you add the Window Manager to it to provide the additional facilities. Nowadays, the two terms tend to be used synonymously, although you should bear in mind the differences.

SMSQ/E comes with the equivalent of all three files built in, so you don’t need to install PTR_GEN, WMAN and HOT_REXT if you are using SMSQ/E. If, like me, you tend to use either QDOS or SMSQ/E from time to time, it can be handy to test if the boot program is actually running on SMSQ/E to prevent it trying to install it when it’s not required. The easiest way to do this is to test the version of BASIC using the VER$ function by adding lines 105 and 135 like this:

135 END IF

As you get used to the system, you can add other toolkits, extensions and so on. As a very broad rule of thumb, install Toolkit 2 and Lightning/Speedscreen first if used, then pointer environment, then any other toolkits, then a HOT_GO command, then any hotkey definitions and anything else.

Some years ago, Tony Tebby introduced the “Colour Drivers” or GD2 system as it’s more properly known. On suitable QL compatible emulators and hardware, this allowed our operating system to use 8-bit and 16-bit colour modes and took our favourite operating system to a whole new level. Later on, Marcel Kilgus extended the system to something called “Window Manager 2” (often abbreviated to WMAN2). Among other things, it gave us greater control over standard program appearances by introducing things such as System Palette, standardised borders, translucent shadows and so on.

The System Palette lets us set up a list of colours to use for the various parts of program windows and menus – the colours to use for loose items (buttons you can press in a program), window background and ink colours, borders and so on. When the system first came out, I agreed to write an article about all this, which meant I had to learn how to use the system and that learning made me realise I rather liked it, so I pestered Marcel Kilgus to produce a programming tool to make it easy to write programs to take advantage of all the clever features he’d added to SMSQ/E. Such a tool already existed (called Easyptr) and Marcel took on the task of extending it to add much needed new facilities to it.

At some point, the original pointer environment files got updated to allow a degree of support for the new window manager facilities. While it didn’t allow the use of more than the original QL colours in QDOS, it did allow most programs written for the new environment to be used in the older environment in the traditional colours as long as you used version 2 of the pointer environment.

There’s a few articles about the Window Manager 2 on my website at http://www.dilwyn.me.uk/docs/smsqegd2/index.html towards the bottom of that page.

So, let’s answer the question, why WMAN2?

For me, it’s about making use of modern facilities available on our favourite computer system, especially the notion of programs taking on a consistent appearance. I use a program called Q-CoCo (which stands for QL Colour Configurator) to set up a “colour theme” so that all my WMAN2-aware software takes on the smooth grey colour scheme – you may have seen pictures on my website of programs such as Launchpad which do this. If ever I get tired of a colour theme, all I have to do is design or use another colour theme (and there’s even a collection of these colour themes on my website at http://www.dilwyn.me.uk/gd2/index.html for you to use).

Screen dump of the Q-CoCo program

Designing a system palette colour theme using Q-CoCo

My only regret really is that there aren’t that many of us regularly writing new software to make use of these fantastic new facilities – people like myself and Bob Spelten jr, for example. It would be really great to see more. That’s why I write my software like this!


4 thoughts on “Why WMAN2?

  1. I think I was 10 years old when I first used the PE and never looked back. I don’t really get how 25 years later it’s still an issue, especially as I made sure that it still works on black box QLs. Yes, not for AH ROMs etc, but supporting them would mean maintaining two separate code bases and I couldn’t be bothered to invest that sort of time for people that can’t be bothered to even upgrade to JS or, gasp, Minerva.
    Anyway, glad that there are still fans of my PE additions around. I was pretty reluctant to take over development of such central components after TT left, but I still think it turned out pretty well 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s