Use of a scalable font as the system font
-----------------------------------------

Start with the DDV prototype that allows simple use of a scalable font.

Fix bugs in this, or scrap and start again as appropriate. Known bugs are:

    after using a font for some time, if I unset Wimp$Font,
    various things don't seem to work properly - eg. typing into a
    writable icon leads to the caret disappearing?
      not sure if this is repeatable, but it definitely happened.
    thereafter the system is unreliable, and can often crash, saying
      that the window with the caret cannot be found.

    random background colour at times - sometimes white, green, black...
      if an icon says 'don't fill background' you should use the
      window background colour.

    some menu entries just missing - white foreground colour?

    'Illegal character in font string' sometimes - e.g. when opening
    windows. Can vary for identical actions, so reading garbage values
    somewhere.

    In some text+sprite icons, the sprite is missing - blanking the
    background on font_paint?
    Perhaps related, *sometimes* on a text+sprite the text background
    partially obscures the icon itself - most noticable on SCSIFiler icons,
      but not always there.

    default action button built using "R6 14" in validation string:
    goes black when pressed, instead of orange.

    Caret sometimes in the wrong position in writable icons, particularly
      when they are initially created.

In addition the following extensions to functionality are required:

The facilities should be turned on and off on a per-task basis, based
on the Wimp version number quoted in Wimp_Initialise.

Provide a global override that forces all tasks to do it, or forces no tasks
to do it. This is mainly for programmers to experiment with.
  wimp$font = font to use
  wimp$fontsize = 23
  wimp$options includes an f -> force all system-font icons to wimp$font
                           n -> force all system-font icons to system font
(or, wimp$options = s23;f if you prefer).

Provide a 'right align' character in text icons. Text subsequent to this
character is right aligned. This is mainly for use in menus, to right-align
the keyboard shortcut. It should work in writable icons too.

Provide underline on/off control in icons - pave way to allow underline to
be used in specifying keyboard shortcuts, in menus and dialogue boxes.
(provide standard values to FontMgr for the size/position of underline)

People use right-aligned strings in text+sprite icons to allow them
to control the exact spacing between sprite and text - provide separate
control of this, via the validation string.

Add auto-computation of menu width. Simply ignore the width that he
publishes. (Does r-click mean you have to recompute this? Might slow things
down. Try doing it like this and see how it goes. If there's a problem, we
might have to insist that the application puts in a width of 0 to
indicate 'please calculate the width for me'.)

Allow the app to get hold of the font handle of the wimp font, e.g. so that
they can measure a string in the wimp font dynamically. This probably
requires a new SWI.

Add a 'shift' character to Homerton.Medium (and others) from Symbol/Sydney,
for use as the shift-key indicator in menu keyboard shortcuts. This is an
ugly solution to this problem, but I see no better one. If you print it in
PostScript it ain't there - people are not recommeded to use it in documents.

Fix the "l40" icon type so that it works with the outline font.

Make the "l40" icon type work as a writable field.

If painting generates an error, fall back to the system font. (particularly
in the Wimp error box)

Update the Task Manager to use scalable fonts. Very little work, just changes
to the menu text I believe.

Update the Palette Utility to use scalable fonts. No work at all required, I
believe, just get the Wimp_Initialise call to declare that it works and menu
widths to be auto-calculated. Update ADFSFiler and SCSIFiler and
ResourceFiler ditto.

Update NetFiler to use scalable fonts. Some work is reqired on the full-info
display of the FS list.

Update the Filer to use scalable fonts. Work is required on the small and
full-info displays. Quite a lot of work on menu width calculation can
probably be removed.

Other updates to improve graphic design
---------------------------------------

Add facilities to allow the tiling of the background of a window with a
sprite. Add facilities that allow the specifying of a standard tile sprite
to use for all windows with background colour n, for n=0 to 15. Perhaps
sprites TileN etc. in the Wimp sprite pool.

Provide a validation string facility in icons that specifys that the
background colour should be the same as the window background, using the
same tile, aligned to the same base. Set this by default if the icon has the
same background colour as the window, and no border. The valid string
control should allow setting both on and off, for cases where there is no
available background colour (e.g. in Wimp_SetIcon).

Provide a new 3D startup screen, along the lines proposed by Chris Murray's
sketch.

Change the visual feedback for action buttons and default action buttons
such that they sink down and to the right by one pixel (or 4 OS units?
experiment), instead of inverting.

An icon button action, or something to put in the validation string, to make
a set of radio icons where ADJUST can *not* lead to no buttons being
selected.

Update drag-a-sprite with the following options:
  drag all sprites half-size
  drag all sprites translucent - mask out every alternate pixel,
    in a checkerboard pattern.
The main complaint people have about drag-a-sprite is that they can't see
the destination. The intention is to experiment as to whether we can help
them on this.

Build in a flashing caret - based on some suitable user choice (an fx or
CMOS setting will do).

In a writable icon, make the caret colour red whatever the icon background
colour.

In a centred text icon, where the text is too wide for the icon, make
the text right-justified.

Make a different crawling drag box, the current one is all but invisible on
VGA, and on LCD. It should be not crawling, and thicker (8 OS-units?). It
may need to be painted (with retention) rather than XOR'd, quite a lot of
work. Let's try a thicker xor'd line first.

Add a facility that allows the application to know whenever the value of
a writable icon changes (by being sent a message). This would probably be
done via a flag in the validation string?

Add a slider/thermometer type icon, which provides slidable bars
of the form needed by a colour picker or the task manager. Valid string entry:
  T<max> [<opts>]
It should fit within a border specified by an R directive, allowing it
to be on a plinth, or in a well, or nothing (if appropriate).
If with an R directive there should be a grey (1) border around the draggable box itself.
If the icon is wider than high, it is horizontal; else vertical.
The thermometer 'mercury' is in the foreground colour, the rest in the
background colour.
The first number in the directive is the maximum extent of the slider value. The
textual content of the icon is the proportion of that which is displayed. A
precise example is available on request.

If a button type that allows drags then the user can change the slider value
by dragging. This changes the displayed value, just as though it were a text
icon. The application is informed whenever the slider value changes - if it
wants to only change things when the slider stops sliding, it should poll
the mouse to see if any buttons are down.

Add other icon valid string effects values that provide the following actions:
  X1,2,3,4      -> if unselecting then grey out icons 1,2,3,4
                   if selecting then ungrey icons 1,2,3,4
  XX 1          -> button action for an inc button for icon 1
  XY 1          -> button action for a dec button for icon 1

(not actually graphic design, but an important behavioural hook): Add a bit to
menu entries that means, do not show this menu entry at all. It is intended for
menu entries that are 'switched off' as not being relevant to this user,
in resource files or whatever. They are not greyed out - the menu actually gets
smaller. This means that menus with no entries must be correctly handled too.

(21-Sep-92 - Beep if a Wimp validation string prevents the typing of a key.
Based on Style Guide meeting about 'the computer not responding when I do
something is unnerving'.)

(30-Sep-92 - Investigate extracting all icon-rendering code from the Wimp
into a separate module. After recent arguments about whether buttons etc.
should be more Windows-3 like, and the success we've had with being able to
change scroll bars etc. without touching the Wimp, I think it would be
valuable to be able to change the appearance of icons as a separate module.)

Updates to improve the handling of error messages
-------------------------------------------------

A new scheme of error message numbering is being introduced, based on setting
high bits of the error number as follows:

Error type 0 -> This is an old error, unclassified.
Error type 1 -> This is a user error. A normal nontechnical user of the desktop is
                expected to understand the text of this error. Typically, the user
                has attempted something that cannot be done.
Error type 2 -> This is a program error. A program somewhere has gone wrong. The
                text of this error is of interest to a programmer, or perhaps
                system implementor, but not to a nontechnical user.
Error type 3 -> This is a resource error. Some critical resource (memory, handles,
                hardware) is not available or is exhausted or has gone wrong.
                Unfortunately the user does have to understand this. This includes
                net not listening, disc error, and so on.
JRoach should define the precise bit mappings that correspond to these.
The bottom 24 bits of any error message will remain unchanged.

The behaviour of Wimp_ReportError is updated as follows. The whole tone is
gentler, less alarming.

For the new errors, there is a new window along the lines proposed in Chris'
visual sketch - this can be supplied. The program can specify more than two
buttons, and can define the text on the buttons. The two default buttons are
now "Continue" and "Cancel". The program can control the title text of the
window. The new error box also allows the application to specify what icon
appears next to the error message, and by convention supplies its own
application icon. All of this requires considerable extension to the
Wimp_ReportError interface definition.

(Aside: I considered adding non-blocking error windows, but I think this is
too hard. It would be controlled by setting an option when the window is
created which causes control to return immediately, and a message to be sent
when the user clicks on a button. Leave this for now.)

For user and resource and old errors, by default they appear with a title
'Message from Foo' and an OK button.

For program errors, by default they appear with a title 'Internal error from
Foo' and Continue and Cancel and Describe buttons, and message text that is
a universal bland remark - 'Foo has suffered an internal error. Click Cancel
to stop Foo'. If the user clicks on Describe, the box then shows the
real error message, changing to just having a "Continue" button (which
gets you back to the initial state).
  (it might also be appropriate, to provide a hook such that if Foo is
running under a debugger, an extra Debug button appears which enters the
debugger. Or, always provide such a button and just provide a *-command
loop by default).

Provide a convenient facility that allows a 'Describe' button to be
provided by a user error, so that an application can provide more detail
in the case of a particular error state.

Provide an escape route such that separate modules can provide handling of
specific error codes. For instance, it should be possible in the future to
provide special handling of 'disc error' which leads the user through
mapping out the defect etc. (Aside - this could also allow profiling, for
instance we could record what errors happened on a computer over a period of
time by building a recording program that took this escape route).

Provide a central facility that allows a single messages file to contain
'Describe' messages for common errors, so that certain events (especially
common resource problems) can include suggested simple actions to relieve
the problem.

If the user presses shift-control ESCAPE at the Wimp, this should kill off
the current task. This leads to a blocking error message "Kill task Foo -
please confirm" with buttons 'Kill' and 'Cancel' and 'Next task'. Clicking
the last of these, changes the question to refer to the next task in the
task list.

Go through the errors in the ROM (in hdr.newerrors), adding the above
classifications. In general, most of the errors there are internal errors.
It may be necessary to leave some alone if they cause widespread
compatibility problems, such as Escape and Disc Changed. These might then
require some special code in the error handler. By default, however, we
should be pushing hard to get the numbers changed to the new scheme even if
this leads to *some* compatibility problems.

It may be sensible to split off the handling of error boxes as a separate
module from the rest of the Window Manager in doing this work. This would
allow the use of C as an implementation language, provided that care is
taken over resulting code size.