Specification for updates to Window Manager and related modules
===============================================================

History
-------
0.01 WS 29-Oct-92 - started - just wimp font work provided.

Background
----------

This is a detailed specification for a package of changes current required
to the Window Manager, and some related modules, by the Libra project. Refer
to Libra market requirement, feasibility statement for further background.

Within the Victoria project I am trying (hard!) to move further towards
writing and reviewing specifications before they are implemented, to
specifications being more complete, and to sticking rigidly to those
specifications. This is a further experiment at achieving this, under
somewhat different project circumstances and for much smaller tasks. Refer
to Mike Challis' current document about what a functional specification
should contain.

All work should be done to full product quality. The enddate does not
correspond to a product release, but the result is likely to be integrated
into a product release in the future. Because of this it is vital that bugs
are not introduced in the course of this development work. Specifically it
is likely that we will release it informally to some high-end users and
developers during 1993, and that it will subsequently become part of the
Victoria RISC OS release.

Any changes to this document should be agreed in advance (extensions AND
restrictions). Jonathan Coxhead, Ian Johnson, David De Vorchik, William
Stoye are the 'review committee'.

Any updates to the SWI interface implied by these changes should be added
to this document and agreed before being implemented.

The work is divided into the following parts:
  work on scalable fonts in the window manager
  other graphic design improvements
  work on error boxes in the window handler
The three phases should be kept strongly separate, in order to help monitor
progress. A product-quality release is expected at the completion of each
phase, and intermediate releases are expected in the first two phases.

This specification is written in terms of differences from the Window
Manager in RISC OS 3.10. Use the PRM, and the Window Manager itself, as the
specification for this.

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

The objective is to entirely replace the use of the system font with the
use of a proportional font within the desktop, in order to make the result
more visually appealing. This may lead to some incompatibilities with
existing applications, but this will be minimised wherever reasonably
possible.

We expect that this will be used most by high-end users, and by those who
possess high-resolution (square pixel) monitors (referred to as VGA
resolution from now on). However, we do not want to exclose those with low
(TV) resolution monitors, and wish to provide them with a reasonable path
forward.

Refer to William's document about future use of dialogue boxes, which
describes the basic approach to 3D and to the use of proportional fonts.

The basic approach is that we will continue to have a single font which is
used for most purposes within the window system. (This contrasts with Windows,
for instance, where numerous different fonts are used for different purposes).
For the purposes of laying out dialogue boxes etc. applications developers
should assume that this font is Homerton.Medium at 12-point.

We expect VGA-resolution monitors to be used with the normal anti-aliased font
as rendered by the font manager. We expect TV-resolution monitors to be used
with a hand-tuned bitmap of this font at 12-point. This bitmap already exists,
obtain from William.

The following changes are required to the Window Manager.

If the variables <wimp$font> and <wimp$fontsize> are set (check this at
startup or at a mode change) then they indicate the font and point-size
which should be used as the surrogate system font ('the wimp font'). This
font should be used to plot icons, window titles, menus and so on in place
of the system font.

(Aside: a prototype Wimp already exists which does this,
with some bugs - get this from David De Vorchik. 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.

    The l40 icon type does not work with this font.

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

In addition the following extensions to functionality are required:

Provide a 'right align' control 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 need not work in writable icons.

When using the wimp font, perform auto-computation of menu width. Simply
ignore the width that the application suggests. (Issue: Does r-click mean
you have to recompute this? This might slow things down unacceptably.
Implement and see if this is so. 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'.) At a right-align character leave at least
the width of one space in the wimp font.

(Aside: the application can get hold of the wimp font handle, in order to do
width calculations, by doing a Font_FindFont of <wimp$font>,
<wimp$fontsize>).

Add a 'shift' character to the Homerton.Medium font 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 isn't there - people are not recommeded to use it in
documents. Add this character to the tuned bitmap too.

When opening a menu, certain character sequences have right-align inserted
into them in order to correctly right-align keyboard shortcuts. Specifically
the following rules apply:

  If a menu entry contains at least one space, and the character after the last
  space is one of "^", shift-arrow, "F", then convert the last space into
  a right-align.

  If a menu entry contains at least one space, and the caracters after the
  last space are exactly "PRINT" or "RETURN" or "ESC", then convert the
  last space into a right-align.

(Aside: this is quite dangerous, as these sorts of rules are hard to
internationalise etc. But, the above rules seem to me quite simple and they
mean that applications writers typically do not have to change anything.)

Update the Filer to work with scalable fonts. The small and full info
display modes both have problems, I'm not aware of any others. It must still
work with the system font too.

Update the NetFiler to work with scalable fonts. The FS list display in
full-info mode is the only problem area that I'm aware of. (Aside: perhaps
a tab-to-absolute-position control sequence in a writable icon would be
helpful in doing this? If so then add it to the Window Manager, as the
result is probably useful to ISVs with similar work to do). It must still
work with the system font too.

(Issue: one could try to look for multiple spaces, and guess that they are
moves to a tabstop. I think this is too dangerous a corruption of the API
to simply apply generally. Perhaps a new icon flag could be defined which
provides this functionality? This would make the update required to the
NetFiler almost negligable. It should not be applied in writable icons.)

I'm not aware of any other significant issues in the ROM. Paint paints some
text in its window as VDU-5 painting, Calc prints its answer as VDU-5 text.
Both of these should be fixed.

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

(full specification not provided yet)

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

(full specification not provided yet)

