This document collects together the Wimp-impacting features suggested in the
RISC OS 3.00 ideas document.

*  Interception of ROM error messages/internationalisation of the Wimp.

Looks:
  No change on the English version. All Wimp generated messages would be
displayed in native language of foreign language versions.

Benefits:
  Lower cost of translating RISC OS to foreign languages.

How:
  TBA

Cost:
  (1 week)


*  Size of icons.
*  Appearance of icons.
*  Improved Wimp graphic design.

Looks:
  The window manager controlled aspects of the desktop's design would be
changed to look better than RISC OS 2.00. Better in this context means
using the graphics features of other windowing system (MSWindows, Open Look,
Macintosh, X-Windows) which give the feeling of quality design to the
desktop. Mostly, this means slab graphics (Buttons which are plinths which
depress when the button activates).

Benefits:
  The RISC OS desktop would aquire a 'more professional' feel to it, and
thus reduce the difficulty in market acceptance in certain market areas.

How:
  The how of this has many options. The options mainly vary the degree of
flexibility given to the changes in window design and the quantity of
spin-off features resulting from their implementation.
(i) Cheap and chearful. This is the minimum effort approach which gives
least spin-offs and least flexibility. This method uses the current method
that the Wimp uses to display the window tools (resize-box, scroll
arrows etc) which is to plot each tool as an icon. The tool icons are all
the same size and have the same icon template as each other. The change from
Wimp 2.00 is that a new icon flag is present 'Border is a slab graphic' and
that the tool icons have a sprite plotted in them. This leaves the window
layout exactly as it is at the moment and gives the option to have slab
graphic tools with non-character glyphs inside them.
(ii) Cheap and chearful, tunable. This is basically the same as method (i),
but the icon templates are individually extracted from a template file. This
allows the user to tune her desktop's appearance as desired, to the extent
that a RISC OS 2.00 desktop could be constructed. The window's outline would
be adjusted to ensure it remained rectangular to encompass the possibly
enlarged icons.
(iii) Extremely tunable. As (ii) above, but the template file contains an
arbitrary number of icons. The icons would identify what sort of tool they
were by an item in the validation string of each icon. The icons would
identify where they sat in relation to the visible work area by they
positional relationship relative to a special 'Visible work area' icon.
There may be several 'visible work area' icons corresponding to windows
whose set of tools is incomplete, each with its own set to tool icons. What
does this degree of flexibility give you? Well, all tools on other windowing
systems which we don't currently have could be implemented (a resize at each
corner and a restricted resize along each edge). The scroll bars could be
repositioned or duplicated (a scroll bar along two edges of a window). The
title bar could be separated from the corner tools. In short, this gives a
huge degree of flexibility. As a spin-off from this a scroll-bar icon type
becomes a necessity.
Doing it:
(i) requires little change to the current code. The icon plotting needs
beefing up to do a slab border, but that's about it. The rest involves minor
small changes to the window tool drawing code.
(ii) As (i) above, with the icon definitions read from a file. This needs
some work on the code as it assumes the window outline is a constant,
whereas it would be determined from the templates file.
(iii) This involves a lot of work where assumptions are made about window
borders being rectangular. The building blocks for non-rectangular windows
are there, but the Wimp assumes rectangularity in many places. Window
moving, window redrawing and closing would all need work.

Cost:
(i) Cheap and chearful. 2 weeks.
(ii) Cheap and chearful, flexible. 3 weeks.
(iii) Extremely tunable. 4-5 weeks.

*  Smaller window margins in hi-res modes.

Looks:
  Window margins become smaller in higher resulution modes.

Benefits:
  More desktop space in higher resolution modes.

How:
  See *  Improved Wimp graphic design for the various options. For this
feature, a different template file of icon set would be used for different
modes.   


*  Icon bar order adjustment.

Looks:
  The wishy-washy desire is for the user to able to pick up icons on the
icon bar and plonk them elsewhere. This sounds fine, but the obvious user
interface of using a mouse drag to move the icon clashes with already extant
user interfaces. I suggest that this feature should not be provided.

Benefits:
  A user can tune her icon bar.

How:
  Once the icon's new position has been determined (somehow) the Wimp has
only to shuffle the icon in its internal structures. and redraw. This is
simple.

Costs:
  1 week.


*  Enhanced display of long text in title bars.

Looks:
  Many possibilities:
        Title is right justified when text is too long to fit.
        Menuing on the title-bar extends it to the text width or shows the text somehow.
        The titlebar stretches off the edges of the window to fit the title text.

Benefits:
  The complete title text would be always readable.

How:
  Depends on looks.

Costs:
  Depends on looks.


*  Mouse blanking on typing characters.

Looks:
  When the user types text which is received by an application with the
caret, then the mouse pointer would disappear until it was moved.

Benefits:
  The mouse pointer does not obscure what the user is typing in. Given the
current user interface construction this often happens.

How:
  In Wimp_Poll if a key press is passed to the caret window then the mouse
would be blanked. If the mouse is then moved (in Wimp_Poll again) the
pointer would be reshown.

Costs:
  3 days.


*  User configurable double click delays/timeouts.

Looks:
  The user could configure the drag delay and the double-click timeout,
probably using !Configure.

Benefits:
  Users could tune their own machine to their own tastes (and make them
unusable for anybody else).

How:
  Make the timeouts be extracted from CMOS RAM, rather than constants built
into the code.

Costs:
  1 week.


*  Caret changes: Enlarged; flashing.

Looks:
  Enlarged caret looks horrible. This has been experimented with and it was
found that this was the case. A flashing caret probably wants to be flashed
only after a certain time after it has been placed.

Benefits:
  A more visible caret.

How:
 Flashing caret would probably be flashed using an OS_CallBack generated by
a timed routine. Some internal state indicating the current state of the
caret would have to be accessible.

Costs:
  2 weeks.


*  Backdrop/sticky desktop: perhaps messing with the desktop window by
applications should be allowed.

Looks:
  Backdrop tasks would no longer clash with each other.

Benefits:
  As looks.

How:
  Implement transparent windows. A transparent window has no background
filling and everything behind it gets redrawn before the transparent window
gets redrawn. This has added benefits in that applications like a real-time
magnifier could be implemented. In detail:
  For the transparent window, redraws come through as normal, and the things
behind the section being redrawn are guaranteed to be valid. Updates happen
as normal: the transparent window must know exactly what it is doing when
updating itself. Window moves cause a complete redraw of the source area and
the destination area just has the transparent window redrawn in it. This is
equivalent of a window close, followed by an open at the destination
location. Window resizing needs no changes. Window scrolling requires a
complete redraw of the visible work area.
  For windows under the transparent window more redraw requests would
happen. When such a window updated itself, areas under a transparent window
would not be updated, but would be redrawn instead.
  As an optimisation to reduce flicker, the Wimp could use the application
free memory as a redraw buffer, redirecting output to it whilst the redraw
sequence takes place, then plotting onto the screen once all the redraws
have finished.

Costs:
  3-4 weeks.


*  Menu historying.

Looks:
  A hot key could be used to reopen previous menu arrangements.

Benefits:
  None.


*  Pack icon - iconifying windows.

Looks:
  Clicking on a new tool in the window's outline would cause that window to
be packed down into an icon on the desktop.

Benefits:
  A tidier desktop, which has a feature like other windowing systems have.

How:
  The Wimp programming interface needs extending to handle presence/absence
of the iconfify tool, and the necessary SWI calls to place a window into the
iconify state. The general desing allows for an iconification application to
be written which may capture iconification requests and translate the
iconification of windows into its own form of iconification. This allows
old-style applications to make use of the iconification feature without
modification, whilst allowing new applications to supply there own
iconification system. Also, a central iconification application may be
written which intercepts all this and can present a uniform, tidy, set of
iconified windows.
  First, I shall describe what happens internally to obtain the given
result. The happenings cover the events that can happen to a window:

Click on iconify.
Message to app - iconify your window.
App Acks the message
  App iconifies its window (closed, but not closed really).
  App broadcasts 'capture iconification' request
  Iconify app acks request
    Iconify app presents iconified window given info in 'capture iconification' request.
    App doesn't receive user_message_ack and does nothing more.
  OR Iconify app doesn't ack request
    App receives user_message_ack for 'capture iconification' request.
    App presents iconified window.
OR App doesn't ack the message
  Wimp receives user_message_ack
  Wimp iconifies the window (closed, but not closed really).
  Wimp broadcasts 'capture iconification' request
  Iconify app acks request
    Iconify app presents iconified window given info in 'capture iconification' request.
    Wimp doesn't receive user_message_ack and does nothing more.
  OR Iconify app doesn't ack request
    Wimp receives user_message_ack.
    Wimp does default iconification.

Iconified window is clicked upon to de-iconify it.
Wimp/Iconify app de-iconify window.

App opens iconified window
Nothing happens, except positional info gets updated.

App closes iconified window
Wimp broadcasts 'iconified window closed'
Wimp/Iconify app dispose of iconified window entries.

App dies:
Wimp broadcasts 'App dying' as currently.
Wimp/Iconify app junk iconify entries for that app.

To expand on the elements required above:
(i) Iconify your window request. This is given to the application in the
form of a user_message_recorded. The message contains the handle of the
window being iconified. The application may either ignore this, or it can
iconify its window and transmit a 'capture iconification' request.
(ii) Iconifying a window. This is, in fact, a call to the Wimp to hide or
show a window. A hidden window responds to open requests, scroll requests
and such like, but does not get displayed. The application can treat such a
window as open, but it won't ever be asked to draw to it. The SWI would
probably called Wimp_HideWindow, with two other parameters, the window
handle and a flag saying whether the window wants to be hidden or shown.
(iii) The 'capture iconification' request contains variable amounts of
information about how to display the iconified window. The wimp generated
version just contains the window's title, the application generated version
may contain further information, such as suggested sprites to use. This is
sent as a user_message_recorded.

The element not specified is when a window gets an iconify tool. Some
heuristic will be applied so that old application's windows get them
automatically in some sensible way. New applications (which are expected to
understand these things) will be able to control whether an iconify icon is
present.

Costs:
  2 weeks.


*  Input focus historying.

Looks:
  When a window is closed or the caret is discarded from that window the
caret appears in the previous window it was in.

Benefits:
  Less desktop faff.

How:
  The Wimp would have to maintain a caret history (one extra entry per
window). When a window was closed or the caret was moved the history would
be updated and the caret adjusted accordingly.

Costs:
  2 weeks.


*  Input focus toggling.

Looks:
  The user would press a hot-key, and the input focus would move between the
windows on the desktop.

Benefits:
  The user wouldn't have to repeatedly swap between the mouse and the
keyboard to move input focus.

How:
  An application could be written to do this. It would have to keep checking
the location of the caret to assess where it can toggle the caret to.

Costs:
  2 weeks.


*  Windows in windows.

Looks:
  Windows would appear to be on the work area of a window. This means that
they would be scrolled under the edge of the window that they were in when
that window was scrolled. A window inside a window would lie above all the
window it's in's icons and application redrawn graphics.

Benefits:
  This feature makes HyperHype implementation much easier. This features
improves pane window implementations greatly.

How:
Conceptual model:
  The desktop shall be a window inside which all other windows reside. The
desktop window  can never be opened inside another window. All windows have
a stack of icons and a stack of windows inside themselves. The order or
drawing, from bottom to top, is: window background; user graphics; icons;
caret; windows. All events are passed to windows regardless of whatever
window they are in. So, for example, a window inside another window would
get mouse clicks and the window it's inside would have no idea what was
happening. When a window performs an open window the windows inside it get
moved with it (relative to the desktop), but stay in the same positional
relationship to each other and the window they are in. The contained windows
do not get any open window requests.

Programmers' model:
  When specifying an open window request the open request block is the same
shape as RISC OS 2.00. The meaning of the behind value is changed slightly.
Suppose window A is inside window B and we open window C behind window A,
then window C will open behind window A and will be inside window B. Opening
behind windows -1 and -2  open the window on the top and bottom of the stack
of windows that this window is currently in. This ensures opening at top of
stack does not cause a window to jump out of a window which it is in. All
windows start inside the desktop window. To open a window at the top or
bottom of another window's stack, the window handle to open behind should be
given as <window handle to open inside>-1 for bottom of stack and <window
handle to open inside>+1 for top of stack (This scheme relies on the fact
that the 'arbitrary number of windows' feature has been implemented as
specified). The programmer, whatever, will be told the shape of a window
handle so that window stack walking can be performed. The desktop will no
longer be window handle -1. The actual window handle will be given. The
iconbar, being such a special case, will still be handled specially and you
shall not be able to open a window inside it. All rectangles used which were
in absolute screen coordinates will still be in absolute screen coordinates.

Internals:
  The flat array of windows will be no more. Windows will have to reside in
linked lists attached to other windows. The redraw code will have to be
extended to cope with the contained windows. Window locations will be stored
internally relative to the window they're in's work area origin. This
lightens the load when moving a window containing a large number of windows.
Internal routines to calculate absolute window positions will have to be
written.

Cost:
  4 weeks.


*  groups of windows.

Looks:
  Colections of windows get moved quicker. An example set is the !Draw tool
window and the main editing window.

Benefits:
  Doubtful whether there would be any. The Wimp would have as much
difficulty getting the block move order right as the application.

How:
  -
Costs:
  -


*  Keypress mouse movement as a general facility.

Looks:
  When in the desktop the cursor keys would move the mouse pointer.

Benefits:
  Fine positioning of the mouse would be much easier.

How:
  Write an application to do this. It must be a grab-keys application which
does the business. This method has the disadvantage that most applications
would be grabbing the relevant key presses anyway. However, it has the
advantage that it's about as good as can be done.

Costs:
  1 week.

*  Keyboard shortcuts.

Looks:
  See any application which performs keyboard shortcuts.

Benefits:
  Experienced users get to use the machine quicker.

How:
  Make RISC OS Lib more available. This performs all that is needed,
especially with o.ctl comming on-line.

Costs:
  0 for the Wimp.


*  Autoscroll speed limited by invariant time source.

Looks:
  Whatever the speed of the machine auto-scroll features would run at a
constant speed.

Benefits:
  Autoscroll features remain usable even when your machine speeds up
considerably.

How:
  Wait for a fixed time before doing an auto-scroll step.

Costs:
  1 day for the Wimp's only auto-scroll-like feature.


*  Windows off left hand side of screen.

Looks:
  Where most windows are stopped at the left edge of the screen, they would
no longer be so.

Benefits:
  Another location to shuffle the windows out of the way.

How:
  Ignore the bounded bit, and make all windows unbounded.

Costs:
  About 2 days.


*  Large virtual screen.

Look:
  The user would be allowed to scroll around an extra-large desktop where
the screen is a window onto it.

Benefits:
  Much less suffering from the 'This desktop is too small' feeling.

How:
  Trivial once windows-in-windows are implemented as specified. The desktop
window either should be given scroll bars or should be auto-scrolled about.

Costs:
  0 with scroll bars on the desktop window.
  3 days to auto scroll.


*  Nailable down menu windows.

Looks:
  There would be a new tool available for windows. This would be displayed
on menu windows and would enable the user to click on it such that the menu
window would stay open until explicitely released by the user clicking on
this tool again. Due to the requirement that this feature should apply to
old style applications, only one menu dialogue box may be nailed up in the
desktop, and it will disappear when a menu is opened.

Benefits:
  Less menu faffing. It is quite often the case that a user will repeatedly
visit a submenu, nailing it up will stop this faffing.

How:
All windows with title bars opened as submenus get a 'tack it up' icon. When
clicked upon, the rest of the menu tree closes, leaving a nailed window.
Wimp_CreateSubMenu will not work until a Wimp_CreateMenu has been performed
whilst there is a nailed-up window. Wimp_CreateMenu will cause the tack-up
window to be closed, and a menu_closed to be sent to the relevant task. The
tacked-up window remains held up until untacked or closed by the
application.

Costs:
  2 weeks.

*  Drag alternative to menu selection.

Looks:
  The user could select a menu item by doing a menu button drag to the item
required then releasing. This does not clash with the menu-click, move,
click method.

Benefits:
  Users used to other systems would be pleasantly surprised that the system
they were used to operates on our machine too.

How:
  The menu button would have to start a drag (internal to the Wimp), which,
when it finished activated the menu item it was over. If there is no item
under it no action is taken.

Costs:
  2 weeks.


*  Two-button clicks and drags as alternatives to shift-click and drags.

Looks:
  To do a shift-double-click or shift-drag two of the mouse buttons are
used. When the user wants to do a one-handed left-shift-double-click (eg to
open a viewer onto the insides of an application) she presses the left mouse
button (and holds it down), then double clicks the right mouse button (the
left button may now be released). To do a left-shift-drag, she presses and
holds the left button, then presses right button and drags. Releasing either
button finishes the drag. Simple swap left and right buttons for
right-shifted operations.

Benefits:
  One-handed desktop use would be possible. This is a great boon for
one-handed users and users who are on the telephone at the time.

How:
  The Wimp would have to intercept ByteV in order to fake the shift key
being pressed. Internally the Wimp would have to detect the double-button
operations and set a 'fake shift' flag which could be detected by the ByteV
routine.

Costs:
  1 week.


*  Springy window reopening to keep windows in old place after mode change.

Looks:
  When switching between screen modes of different sizes the windows would
maintain their original position (until moved by hand) so that when
returning to the larger screen modes the windows return to their original
size and position. This avoids the window-clustering effect where the
windows get shuffled into the bottom left ahdn corner of the screen when
toggling modes.

Benefits:
  Happier users.

How:
  The Wimp would have to maintain for each window a 'natural' size which is
the last size set by the user. To do this the Wimp would have to note
whether it was likely that this Wimp_OpenWindow was caused by a
Wimp_OpenRequest. If it was, then the new OpenWindow details become the
natural position, otherwise the natural position stays unchanged. When a
mode change occurs and the Wimp sends OpenRequests to all applications, then
the natural positions will be sent, thus causing a spring back to the
windows' old positions.

Costs:
  2 weeks.


*  Scrolled-off window sections cached.

Looks:
  Scrolling windows would be faster.

Benefits:
  As looks, applications wouldn't have to do this.

How:
  The Wimp could use the application free space to hold scrolled-off
sections of windows and could plot them directly when scrolled back on. This
requires a scrolled-off bit management system to be implemented which
involves the scrolling, change work area and redraw sections of the Wimp to
get involved.

Costs:
  5 weeks.


*  Infinite desktops.
*  Desktop in a window.

Benefits:
  None that I can think of.

How:
  -
Costs:
  -


*  Remote Wimp.

Looks:
  As now, with a window's controlling program running on a remote machine.

Benefits:
  One, central program controlling windows on other machines. This has
benefits in the classroom situation, and groupware applications amoungst
others.

How:
  For 'needs help' windows (windows which the Wimp cannot completely redraw
itself) a remote graphics protocol is needed too. For other windows (eg
dialogue boxes) the local Wimp can redraw them itself. For communications
between the machines a remote procedure call standard needs to be used.

Costs:
  Quite a lot.


*  New wimp (without hacks).

Looks:
  Same as now.

Benefits:
  Easier to maintain Wimp.

How:
  Work gradually to remove the hacks as maintenance work is done.

Costs:
  Hidden in other activities.


*  *Taskensure

Looks:
  There would be a new Wimp provided command, *TaskEnsure. As its first
arguement the would be a task name (Edit, EMail etc), followed by a command
to be executed if a task of the required name does not exist.

Benefits:
  Less task duplication.

How:
  Look for the required task and do a Wimp_StartTask if it's not there. This
is probably best implelemented in the Switcher which knows about these
things.

Costs:
  1 week.


*  Improved use of RMA (iconsprite purging..)

Looks:
  No change.

Benefits:
  More memory for the user.

How:
  ?

Costs:
  Depends on how.


*  Multiple poll-word support.

Looks:
  No change.

Benefits:
  The Wimp could be used to poll multiple pieces of hardware. This is
probably not worth the while, as a small piece of assembler interupt code
could set the application's poll word anyway.

How:
  -
Costs:
  -



*  Lower level event stream.

Looks:
  No change.

Benefits:
  Event ordering and shifting-key detection synchronisation would be
improved. This would make shift-dragging etc whilst the Wimp was being
delayed work much better than currently.

How:
  Assuming the operating system has implemented the low level event stream
then the key press and mouse event handling would have to be rewritten to
handle the new event stream. This handling is mainly done in the Wimp_Poll
handling code.


*  32-bit graphics interfaces.

Looks:
  No change

Benefits:
  (Slightly) faster Wimp.

How:
  Use the 32-bit graphics interfaces, rather than VDU stream.

Costs:
  Depends how many non-VDU interfaces are provided.


*  Event mouse-moved.

Looks:
  No change.

Benefits:
  Applications which depend on following the mouse would be slightly easier
to write.

How:
  This feature, as it's not very useful, is not worth detailing.

Costs:
  -


*  message_Something's moving

Looks:
  Applications which want to follow moving things could do so.

Benefits:
  Cute applications like !Follow (a pair of eyes follow the mouse about the
desktop) could be improved to follow the nearest moving object.

How:
  Document the new message.

Costs:
  1/2 day.


*  Multiple dead wimp task support.

Looks:
  No change, initially.

Benefits:
  A dead task (one which hasn't done a Wimp_Initialise yet) could start
another task off. This ties in better with a move to an alternative kernel.

How:
  A dead task should be given a pages entry in its task block so that it can
be paged in and out. It might need a flag adding to indicate dead-ness.

Costs:
  3 weeks.


*  Suspended wimp tasks - option here for pre-empted wimp tasks and
multiple redraws at once.
*  Kill hogging task from task manager (implies pre-emption).

>>>>>>>>These are just too horrible to implement for words<<<<<<<<<<<<<<


*  VM

Looks:
  There should be no discernable difference in normal use.

Benefits:
  RAM limit gone.

How:
  Use a new kernel which VMs for us.

Costs:
  Unknown at this stage. Probably not too bad for the Wimp, as all it needs
to do is operate in USR mode and use the new kernel's VMing features.


*  Message passing across machines.

>>> Not necessary for the Wimp to get involved here <<<


*  Fixed limits being removed (windows and tasks).

Looks:
  The error messages 'Too many tasks' and 'Too many windows' would become
much rarer.

Benefits:
  The 'Too many windows' error was encountered often under RISC OS 2.00 due
to the need for some applications (!FormEd in particular) to have many
windows created at one time. Whatever small fixed limit is placed on the
number of windows or tasks at some stage somebody will hit it. Having a
large (and, effectively infinite) limit on the numbers of these will
circumvent this problem.

How:
  The window manager currently keeps a fixed sized table for each of tasks
and windows. This cannot be made large enough to handle a huge number of
tasks or windows without a huge penalty in memory terms (4 bytes per entry).
Just how big a penalty will it be? The Wimp needs to be able to distinguish
between Task handles, Window handles and Menu pointers. Of those the Wimp
generates Task handles and Window handles internally, and so it has complete
control over them. Menu pointers, generated externally, must lie on a word
boundary (and are almost certainly in application space, RMA or ROM). This
means there is space, in the space of numbers, for about 3000,000,000 window
and task handles. At 4 bytes each this would somewhat exceed the maximum
concevable address space of an ARM machine, present or future. Clearly, some
other scheme is required.
  The reason the Wimp keeps a table of windows is so that it can move its
internal window structure about when its icon list changes. This is required
as the icon list is butted onto the end of the window's data structure and,
when icons are added, the whole structure might have to move. If the icon
list was a seperate RMA block then the window block would never have to be
moved, and so the window handle could be a simple derivative of the window
structure's address. If such a simple derivative is exported then there must
be a guard word placed inside the structure to verify it is a window
structure. The derivative is the window structure's address plus 1 (one),
which ensures that clashes won't occur with Menu handles (window structures
must be word aligned). Task handles have somewhat more stringent
requirements. First, they must not clash with window handles, second, a task
handle must not be reused soon after a task has died, and third, a task
handle must be non-negative. The second requirement implies that a simple
derivative of the task structure's address is inadequate. As the number of
tasks is likely to remain small, a quick look-up from handle to task block
is not required, and so the task blocks shall be held in a two-way linked
list. Task handles shall be allocated in numerically increasing order, with
a uniqueness check to avoid reuse on wrapping around the end, and that task
handles shall always have a value 4n+2 where n increases by 1 for each new
task. A task shall be found from its handle by testing each task in the task
list.
  The areas thus affected are:
        Icon storage. Each window shall have an icon pointer which points to
                where its icons are stored.
        Task look-up. Windows can point directly at their owner's task
                block, task handle lookup can be done by a subroutine.
        Window/Task handle/Menu address distinguishing.

Costs:
  3 weeks.

*  32-bit PCs

Looks:
  No change

Benefits:
  32-bit program counter machines would not stop the Wimp from working.

How:
  Unknown

Cost:
  Unknown


*  Non-three-button mice.

Looks:
  As the user interface for this is not well defined, if at all possible,
this feature shall not be detailed.


*  Use OS_CheckModeValid to disallow Wimp_SetMode to invalid mode

Looks:
  Fewer bad wimp modes are selectable. All Wimp mode setting commands would
be more stringent in their acceptance of modes. In particular all modes
which got mapped to mode 0 would become unacceptable.

Benefits:
  Fewer bad wimp modes would be accepted

How:
  Use OS_CheckModeValid when checking for a valid wimp mode and reject
remapped modes.

Costs:
  2 days.


*  Stop menus from being forced back on-screen on right-click

Looks:
  Where now, if a menu item is right clicked it is forced entirely on the
screen, this would not happen. This means that clicking on a menu half off
the screen would leave it where it was.

Benefits:
  The desktop would be doing a more expected thing.

How:
  When reopening a menu the menu windows shouldn't be opened with 'force on
screen' flagged.

Costs:
  2 days.


*  Keep submenus above iconbar as well

Looks:
  Where the Wimp ensures the root menu doesn't obliterate the iconbar it
should also do the same for child submenus.

Benefits:
  Smarter desktop.

How:
  Perform the same check as is done for the root menu on the child menus.

Costs:
  A week.



*  Move parent menu if submenu is at edge of screen

Looks:
  When a submenu is opened at the edge of a screen such that it would
normally obliterate its parent, then the parent would be moved aside to not
get obliterated.

Benefits:
  Less menu thrashing on the menus of those applications at the screen edge.

How:
  The Wimp, when opening a submenu, should check for parent obliteration and
take corrective action as appropriate (this involves reopening the
obliterated menus to one side).

Costs:
  3 days.


*  allow panes in menu dboxes

Looks:
  Window in window in a dbox hanging off a menu tree.

Benefits:
  This can be done with the menu tree staying open.

How:
  Recommended to implement using the windows in windows feature.

Costs:
  Free once windows in windows have been implemented.


*  re-open menu tree beyond dboxes if required

Looks:
  When a menu tree is reopened menus beyond dboxes should be reopened too.

Benefits:
  A bug removed from menu handling.

How:
  Don't stop reopening a menu tree once a dbox has been reached.

Costs:
  3 days.


*  optimise panes entirely within tool window

Looks:
  No change.

Benefits:
  None if windows-in-windows are used instead. As panes, the movement of
window collections would be quicker.

How:
  This is hard, and requires divising some sort of heuristic to determine
when to pend window movement to after all panes have moved. Generally
pending window movement requires much work in the way the wimp moves
windows.

Costs:
  Much.


*  fix bug re: pointer palette being reset to Wimp palette

Looks:
  When a pointer which as been defined using a sprite which has a palette is
currently displayed then changing the pointer colours using the palette
utility or loading a palette would not change the pointer's colours.

Benefits:
  Odd pointer colourings wouldn't occur.

How:
  Remember how the pointer was coloured when it was last set (ie did the
defining sprite have a palette). If, then, when the pointer colours are
changed the pointer was defined with a sprite with a palette then the
pointer colours won't change as they have been overidden by the sprite's
palette. This must be done by intercepting OS_Word.

Costs:
  1 week.


*  Restore command / error window width after expansion

Looks:
  After an error has been reported or command window executed which had a
wide title, then relevant windows would be narrowed back their original
width. In RISC OS 2.00 this did not happen.

Benefits:
  Tidier desktop.

How:
  When an error/command window is closed its original size should be
restored.

Costs:
  1 day.


*  make rectangle area expand dynamically

Looks:
  No change.

Benefits:
  Less memory used by the Wimp, "Rectangle area full" problems less
frequent.

How:
  The rectangle handling routines would be addapted to use an
expanding/shrinking rectangle area.

Costs:
  1 week.


*  Wimp_LoadTemplate shouldn't load indirected data to scratch buffer first

Looks:
  No change. Internally, the scratch buffer supplied by the caller of
Wimp_LoadTemplate does not need to be longer than the window definitions, ie
the indirected icon strings get loaded straight into the indirected data
area supplied by the caller, rather than going via the scratch area.

Benefits:
  Use of Wimp_LoadTemplate becomes more obvious.

How:
  Addapt Wimp_LoadTemplate to load its indirected data to the caller's
supplied indirect data area.

Costs:
  1 week.



*  System font versions of chars &8F..&9F

Looks:
  The system font has the same character definitions as the font system
character sets.

Benefits:
  All fonts on the system are the same.

How:
  Redefine those characters in the OS.

Costs:
  2 days.


*  Make instant dragging the default in the Wimp

Looks:
  A fresh out-of-the-factory machine would have window drags instant
automatically.

Benefits:
  A novice user would be given instant effect window drags without having to
grobble about with the !Configure application.

How:
  Change the XOR mask applied to the CMOS bits, thus toggling the effect of
the instant effect window drags bits.

Cost:
  1 day.


*  Restore caret correctly on menu re-open.

Looks:
  When a menu is reopened (eg by the Filer recaching a directory whilst a
menu is up) and a caret was in a menu text field, then that caret would be
replaced in the corect position in the text field.

Benefits:
  Typing could continue uninterupted across a menu reopen.

How:
  Remeber the position in the icon across a menu reopen so that it can be
replaced there, and replace it there when the reopen happens.

Costs:
  3 days.


*  Return pointer to scroll bar after a 2D drag

Looks:
  After a 2-D scroll the mouse pointer would appear where it started
relative to the scroll bar.

Benefits:
  Less user confussion.

Method:
  Remember the position across the scroll bar that the pointer started at,
then move the pointer there when it gets displayed at the end of the scroll
operation.

Costs:
   Week.


*  Wimp_GetMenuState can't tell you if the menu tree is open - if the
     pointer is not on the root menu and there are no submenus open.


*  Drag a sprite

Looks:
  No change initially. This takes the part of an enabling techknowledgy
which allows application to easily drag a sprite, rather than a rotating
outline when a drag operation is in progress.

Benefits:
  A more impressive desktop.

How:
  Possibly the Wimp, or possibly another module, could provide all the
painful parts to implementing this solved. This involves managing the memory
for dragging a sprite and providing the draw, undraw and move routines.

Costs:
  2 weeks.

   
*  Arbitrary shaped windows.

Look:
  Round-edged windows would be displayable efficiently.

Benefits:
  A smarter desktop. Faster redrawing.

How:
  Depends on how the graphics changes shape up.

Costs:
  Unknown yet.


*  Wallpaper support.

Looks:
  A patterned background to windows and icons would be possible.

Benefits:
  A prettier desktop. Backdrop patterns wouldn't clash with other backdrop
applications.

How:
  Depends on details of wallpaper support. Assuming a sensible
implementation, icon redrawing would need extending to handle a wallpaper
background fill.

Costs:
  1 week.

