Allow a different set of window toolicons for the window with the input focus.
Steve Revill authored
Detail:
  Previous versions of the Window Manager required toolicons to have pixels
  that were transparent so that the background colour could be used to indicate
  whether a window had input focus or not. This means that new sets of toolicons
  either have to have transparent pixels or lose indication of input focus.
  To remove this limitation the support for toolicons has been extended so
  that a different set of toolicons can be used for the window with the input
  focus.

  The new icons have the prefix 'f' added to their names as follows:
    <toolname>    standard version of toolicon
    p<toolname>   pressed version of toolicon
    f<toolname>   focus version of toolicon
    pf<toolname>  pressed+focus version of toolicon

  Code has been added to ensure that all toolicons are represented.
  This is done in two stages; first the pressed icons are checked and for any
  missing its non-pressed equivalent will be filled in. Next the focus icons
  are checked and for missing ones its non-focus equivalent will be used.
Admin:
  Tested on Iyonix RO5.11
Author:
  Fred Graute

Version 5.03. Tagged as 'Wimp-5_03'
58925e79
Name Last commit Last update
Doc Added a quick note to direct people to the drag-and-drop spec.
Options/s Icon bar Shift F12 behaviour changed back to RISC OS 3.7 style, which made far more sense than the bizarre "simplified" scheme some Ursula spec review cooked up.
Resources Added soe documentation on API changes since Ursula.
Test Added a test harness that may be useful if anyone fancies finishing off drag and drop in writeable icons.
TestO New Wimp imported
hdr Third-party validation string symbol noted for reference.
rm Import from cleaned 360 CD
s Allow a different set of window toolicons for the window with the input focus.
.gitattributes ARTtmp branch folded in
BlackLog ARTtmp branch folded in
LICENSE Import from cleaned 360 CD
Makefile BBE tidying.
MkClean,fd7 Updated build structure to use the shared AAsmModule makefile.
MkExport,fd7 Updated build structure to use the shared AAsmModule makefile.
MkGPA,fd7 Bugfixing, Sprites11 support and stretchy command windows.
MkRom,fd7 Updated build structure to use the shared AAsmModule makefile.
ReadMe Merged WIMP imported
UrsulaLog Ursula branch Wimp merged back onto trunk.
VersionASM Allow a different set of window toolicons for the window with the input focus.
VersionNum Allow a different set of window toolicons for the window with the input focus.
Notes on Wimp sources
---------------------

At the bottom of the Options file, I've set a few of the options to
the values that are required for me to test the code on my RISC PC -
if you set the switch to false, it'll use the settings that were
present when I received the sources - I don't know if those are the
settings you need for the NC or not.

The debug option is also on, so you may want to turn that off as well.

Apart from that, the only other thing you need to do is to add the
following message token to the Wimp's message file:

    BadParent:Sorry, child windows cannot be nested

It's probably not worth integrating my changes with yours just yet,
since I've about to embark on the next phase of development (nested
child windows etc.).

Let me know if you have any problems compiling the Wimp with these
sources.


Summary of test routines
------------------------

The main test program is Test.Nest1, which has a whole bunch of
keyboard shortcuts with which you can insert windows inside each other
in various nefarious ways.  The actual keys are listed in the program.

Test.Many is designed to check that braindead panic redraw works with
child windows.  This is what happens when the Wimp's rectangle
arithmetic overflows its rectangle list, thus requiring a more direct
approach to redraw the screen (start at the back and redraw everything
in turn, without worrying about which bits overlap).

Note that the Wimp's new redraw algorithm is much more sophisticated
than the old one, as it collects up all Wimp_OpenWindows since the
previous Wimp_Poll and performs them together, which allows it to do
far more block-copies (rather than redraws) when moving pane windows,
and can often move a parent and all its children with a single
block-copy.

Normally the new algorithm makes better use of the rectangle area than
the old one, but since it uses two lists of invalid rectangles, it's
possible that under some circumstances it may perform worse than the
old one, in which case I'd be interested to know about it.

Test.Multi is designed to show off the new multiple-block-copying
stuff, in that a series of child windows is being moved in a circle. 
Where each rectangle overlaps the one after it, the old Wimp has no
choice but to redraw all but the first one, whereas the new code is
able to block-copy all but one of the rectangles.