CONFIG Level 2
==============

We felt that a number of things were missing in the definition of level 1 of
the QJUMP Standard configuration definition. Therefore, after a number of
discussions, the following suggestions were made to be implemented on level 2.
This will take a while, and we are happy to receive comments and/or suggestions.
Please leave any messages in message area 10 (German) or, preferably, in area
11 (QDOS English).

First of all, re-configuring software you already had in previous versions is
a very boring thing. Most of the time, all you do is set the old settings in
the new file. This has to be made automatic. Therefore, the item structure is
expanded to make room for an config-item-ID, i.e.

The configuration level 2 consists of the following information:

        Configuration ID
        Configuration level
        Software name
        Software version
        List of
            Item ID (long)                    <---- NEW!!!
            Type of item (string, integer etc.) (byte)
            Item Selection keystroke (byte)
            Pointer to item
            Pointer to item pre-processing routine
            Pointer to item post-processing routine
            Pointer to description of item
            Pointer to attributes of item (item type dependent)
        End word (value -1)

The ID should be unique for every item. There may be global ID names, which
could be used by many programs (like the colourway setting), there can be
unique "registered" ID names (which are preferred) and there may be
"unregistered" local ID names. Global ID names should start with an underscore,
unique ID names should start with a letter. For unregistered local IDs, the
top byte of the ID has to be 0.

For all ID names, a list which is maintained by Jochen Merz Software is
created, to avoid multiple name conflicts. If you wish to register for
one or more ID names, please write to Jochen Merz Software and enclose
an I.R.C. You may suggest one or more name, otherwise JMS will try to
find a sensible abbreviation for you.

ID names consist of a longword (i.e. four characters). The first three
characters have to be reserved by JMS, the fourth character can freely
be assigned by the software house for the various items.


The function of the CONFIG program
==================================

When the CONFIG program starts up, the user selects the file to configure
(which should contain one or more level 1 or level 2 config blocks). Level 1
blocks are treated as before (i.e. they can be printed or configured), but
for level 2, there is an additional UPDATE facility. CONFIG "learns" level 2
configurations and stores the settings of the item for any ID in a separate
file, giving a "global" default configuration file. When the user selects
UPDATE, the config block is scanned for IDs, and every ID is checked in the
global default configuration file. If it is found, the preferred setting is
automatically copied in the file which is to be configured. This way, updating
programs is MUCH easier and nearly automatic. In fact, in could be made
completely automatic (via parameter string).
Another advantage is, that the configuration can be made language-independent.
The "learned" configuration of an English file could be used to configure
a German or French file, for example, provided that the sasme items have got
the same ID's. Care should be taken for items, which are language-dependent
filenames (i.e. help-files, auto-save filenames etc.), which SHOULD have
different ID's, otherwise the German program would save to an English file
or vice versa.
Local IDs are not stored by MenuConfig. When a user wants to update a file
containing local IDs, then MenuConfig has to "learn" the old settings from
the old (already configured) version of the file, and these settings are
then updated to the new version of the file. The local IDs are not stored
anywhere else, as this could lead to ID clashes between different files
containing the same local ID for different purposes.

MenuConfig V2 stores the learned settings in a file called MenuConfig_INF
on your current PROGram default device. It will try to read it from there
the next time to execute MenuConfig. You can, of course, tell MenuConfig
to load a different _INF file containing other configuration information,
for example if you prefer having different configurations for colour and
monochrome versions (!). When you terminate MenuConfig and you changed or
learned new settings, MenuConfig asks you whether you want to update the
_INF file, so that the settings are preserved for the next update.


An additional item type
=======================

It became obvious in MenuConfig, that a new item type "nothing" or "all" is
required, which does not do anything automatic but calling the pre/post-
processing routines. This is useful for proving own menus without having
to mess around with unwanted texts. In addition, more information is
required to be passed to these pre/postprocessing routines. We think, at the
moment, of the following scheme:

A3, which points to a 4kBytes space, is negative indexed and provides the
following information:

 $0000  4k      base of workspace passed to pre/postprocessing routine
-$0004  long    MenuConfig's version
-$0008  long    primary channel ID
-$000c  long    pointer to working definition
-$0010  2 word  primary window x/y size
-$0014  2 word  primary window x/y origin
-$0018  2 word  work area x/y size
-$001c  2 word  work area x/y origin
-$001d  byte    text info window number in working def
-$001e  byte    work info window number in working def
-$0022  long    window manager vector
-$0026  long    pointer to filename of the file being configured
-$002a  long    pointer to buffer containing file being configured
-$002e  long    pointer to buffer of default directory
-$0032  long    pointer to buffer of output device
-$0040  long    colourway


WORKING COPY
============

If the configured file contains a flag "<<QCFC>>" BEFORE the "<<QCFX>>"
flag (which can be generated with the new Macro MKCFCUT) then MenuConfig
offers the user the choice to save a configured version without the config
texts, to reduce the required file size to the minimum (as the configuration
texts are not required anymore after configuration). Of course, a file
treated this way cannot be configured afterwards anymore.
Programmers should take care that the configuration items come BEFORE the
configuration texts, otherwise they will be cut away too. So make sure that
the configuration texts are always the last section in your file!!!



LIST OF GLOBAL ID'S
===================

_COL    Main Colourway          Byte    range -1, 0 to 3.
_COS    Sub-Window Colourway    Byte    range -1, 0 to 3.
_COB    Button Colourway        Byte    range -1, 0 to 3.


LIST OF RESERVED ID'S
=====================

ATA.    ATARI-Rext
DRN.    Disk Rename
EMU.    ATARI-Emulator
EPM.    EPROM-Manager
FiF.    FiFi
HLP.    HyperHelp
MBT.    MultiButton
MCF.    MenuConfig
MEN.    Menu Extension
MPK.    MultiPick
PAD.    Notepad
PRP.    PrinterPanel
PRM.    QPrommer
QBS.    QBASIC
QDA.    QD (Tab Options)
QDE.    QD (Editor)
QDF.    QD (Files)
QDG.    QD (General)
QMK.    QMake
SST.    Systat
TAB.    QSpread
TAb.    QSpread
TaB.    QSpread
Tab.    QSpread
TRA.    TRA Extension
WED.    WIN Ed
