Feasibility study for the Filer.

Cost (nearly)0 features:

*  Background operations

Looks:
  When a long duration operation is started a dialogue box is opened
displaying the progress of the operation. The operation does not hold up use
of the desktop whilst it is happening.

Benefits:
  A more satisfied user. The desktop remains useable for longer, thus the
user is happier using it as she can continue on with other work. Also, the
display of information is more alike to other RISC OS applications and does
not butt in with command-line like pieces of text like RISC OS 2.00 used to.

How:
  A seperate module, Filer_Action, is written which performs all such
background Filer operations. It is invoked by starting a Wimp task using the
command *Filer_Action. It waits for control messages to be sent to it. If no
messages are received it kills itself off. The control messages tell it
which files are to be operated upon and what operation to do upon them.
Whilst performing the operation Filer_Action does many Wimp_Polls in order
to keep the desktop alive. Other control messages may be sent to tell it to
hide and show the progress window. See implementation for more details of
its user interface.

Cost:
  About 2 weeks to polish off the last bugs.


*  Copy=>save box

Looks:
  The RISC OS 2.00  File 'fred'=>Copy=><name>  sequence is to be replaced
by  File 'fred'=>Copy=><save box>. The semantics of this save box are the
same as save boxes elsewhere in the desktop.

Benefits:
  An object can be copied from anywhere to anywhere else under a different
name. This enables files to be moved more freely across diverse filing
systems. Take as an example NFS to ADFS. On NFS a file name can be very long
(more than 10 characters long), whereas ADFS file names are limited to
10 characters. The copy save box allows an alternative name to be used when
copying to ADFS, thus avoiding the necessity under RISC OS 2.00 to renaming
or copying the source object on NFS.

How:
  The Filer_Action module is used to do the main work of copying. The user
interface is straight-forward and so does not require detailing.

Cost:
  None - this is implemented and there are no outstanding bugs classified
under this feature.


*  Sort out access options
*  Access=>menu=>details

Looks:
  The RISC OS 2.00 access submenu is complex and uninformative to a novice
user. This is to be changed to a submenu which allows the choice of the
commonly desired access options: Protected; Unprotected; Public; Private and
an Other entry leading to a dialogue box allowing fine control over the
access bits of objects. Where appropriate the relevant entries will be
ticked to correspond to the currently selected objects. The Others dialogue
box allows individual access bits to be set, cleared or left alone, which
gives greater functionality than the RISC OS 2.00 dialogue box which only
allowed setting or clearing. When an access setting is clicked upon a
background Filer_Action is started and the ticks are updated as the action
progresses.

Benefits:
  Happier users. The novice user is presented with a simpler to understand
user interface for setting the access to her files. The experienced user has
more control over the access bits of her files.

How:
  Once again, the Filer_Action module performs the operation in background.
The user interface is managed in a normal fassion, no details need be given.

Cost:
  None.


*  Info=>

Looks:
  On the File 'blah'=> sub-menu a new entry 'Info' will be added. Off this
will hang a dialogue box which gives the full information about the selected
object.

Benefits:
  Happier users. In RISC OS 2.00 it was often the case that a user would
toggle between Display=>Full Info and Display=>Small Icons just to get the
full info for one object in the viewer. This caused irritation. This new
feature would obviate the need for such faffing, thus increasing the
desktop's useability.

How:
  In the obvious way.

Cost:
  1 day to fix the remaining bug.


*  Find=>

Looks:
  This File=> submenu entry allows the user to search for a particular
object amoungst the selected items. The search is performed in the
background, allowing the user to carry on doing other things. Once found the
user can select to carry on the search, view the found object or run it.

Benefits:
  This feature is extra functionality over RISC OS 2.00.

How:
  As usual, Filer_Action does the work. 

Cost:
  None.


*  Set type=>

Looks:
  This File=> submenu entry allows the user to type in the new type to set
all the selected objects to. The operation is performed in the background.
As an extension to this, a list of currently known file types may be
presented.

Benefits:
  In RISC OS 2.00 this feature did not exist from the desktop.

How:
  Filer_Action again.

Cost:
  None, without the list. 1 week to implement the list presentation.


*  Stamp

Looks:
  This File=> submenu entry stamps all selected objects with the time now.
Clicking here starts the operation in background.

Benefits:
  In RISC OS 2.00 this feature was not available on the desktop.

How:
  Filer_Action again.

Costs:
  None.


*  Improved window opening

Looks:
  In RISC OS 2.00 the Filer directory viewers gave the distinct impression
of being opened in random positions across the screen. This was most
confusing. In RISC OS 3.00 the algorithms will be improved to give the user
more confidence in the desktop.

Benefits:
  Happier users.

How:
  Tinker with the directory viewer and sub-directory viewer opening
algorithms.

Costs:
  None. The current, internally available implementation seems to have got
this right.


*  Translation of desktop messages

Looks:
  On English machines there should be no visible change. On foreign
machines, all messages should be in the native language.

Benefits:
  Cheaper (for Acorn) translation of messages to foreign languages.


*  Longer filename support.

Looks:
  The look remains the same as RISC OS 2.00 in all cases.

Benefits:
  When the Filer is asked to handle a longer filename than it was used to in
RISC OS 2.00 it should not longer crash. This is necessary to support future
filing systems (eg NFS).

How:
  Increase the size of internal buffers to Filer to handle the longer
filenames.

Costs:
  None. This has already been done.


*  Extended Filer_OpenDir command

Looks:
  The Filer_Opendir command sprouts more options. These allow the user to
specify the size, sort mode, display mode and location of a viewer to be
openned.

Benefits:
  This enables desktop saving support to be implemented properly.

How:
  Extend the internal interfaces within Filer to cope with the extra
parameters. Implement the interpretation of the parameters.

Costs:
  None. This has already been done.


*  Extended Filer_CloseDir command

Looks:
  The Filer_CloseDir command would GSTrans its parameter before using it.

Benefits:
  This allows the user to specify the directory to be closed by variable
name rather than actual string. This gives greater flexibility to the user
at no cost.

How:
  Set the GSTrans bit in the command table entry for Filer_CloseDir

Costs:
  About 2 seconds, but its already been done.


*  New Filer_Boot command

Looks:
  The Filer_Boot command boots an application as if it had just been seen by
the Filer.

Benefits:
  This allows desktop save to be supported correctly.

How:
  Implement the desktop_boot command to perform an application boot
sequence. Minor reorganisation within the Filer to enable this.

Costs:
  None. It's already been done.


*  New Filer_Run command

Looks:
  The Filer_Run runs an object as if it had been double-clicked upon inside
a directory viewer. This causes already running applications to capture that
object and edit it directly instead of causing the application re-running
and thus having two icons on the icon bar.

Benefits:
  A tidier desktop. Users of 1MByte machines get more power from their
restricted environment.

How:
  Perform the sequence of events for a double click.

Costs:
  None. It's already been done.


*  Desktop saving support

Looks:
  See desktop saving specification.

Benefits:
  See desktop saving specification.

How:
  The Filer identifies itself as started after all filing system filers have
started. This ensures the correct order when desktop saving happens. The
Filer also saves, on request, Filer_Boots for all applications it has booted
and Fier_OpenDirs for all viewers it has opened. The viewers open in exactly
the same place as they were saved in.

Cost:
  None. This has already been implemented.


Non-0 cost features:

*  Translation of non-desktop messages
*  Intercept ROM error messages

Looks:
  The help and syntax messages for *-commands should be translated before
displayed and all error messages translated similarly.

Benefits:
  Cheaper translation of the Filer.

How:
  No details fo the supplied mechanisms have been given.

Costs:
  1 week.


*  Internation sorting

Looks:
  The collating order for sort-by-name changes on change of configured
language.

Benefits:
  Foreign language configurations have their files sorted in the native
language's sorting order.

How:
  Mechanism TBA.

Costs:
  3 days.


*  Time zones

Looks:
  The display format of dates changes on change of configured language.

Benefits:
  Foreign language configurations have their dates displayed in the native
language's format.

How:
  Mechanism TBA, probably only need to change date display control string
in templates file.

Costs:
  1-3 days.


*  Visual indication of location of already-open viewers being opened.

Looks:
  Some form of visual affect should be performed to highlight the location
of an already-openned directory viewer.

Benefits:
  The viewer would be found much more easily.

How:
  For a line-based zoom feature XORed lines would be drawn. Another method
may be adopted such as flashing the title bar.

Costs:
  3 days (assuming a line-based zoom, or flashing the title bar).
         

*  Right selection generating an error box shouldn't close parent.

Looks:
  If the user right-clicks in the directory viewer which runs an application
which fails to run, then the directory viewer clicked in doesn't close.

Benefits:
  Less faff in using the desktop.

How:
  If a Service_WimpReportError occurs before the XWimp_StartTask returns,
then don't close the parent window on right-double-click.

Costs:
  1 day.


*  Pack icon

Looks:
  See Wimp feasibility study

Benefits:
  Less cluttered desktop, and desktop more comparable with other windowing
systems.

How:
  Support Wimp feature as described in feasibility study. The Filer's
iconified viewers would have their own menu with useful things on it, such
as open parent, options, remove.

Costs:
  1-2 weeks.


*  Nailable menus

Looks:
  See Wimp feasibility study

Benefits:
  See Wimp feasibility study

How:
  No work. The Wimp should do it all.

Costs:
  -

*  Infinite desktops

Looks:
  Many windows, each with a desktop in it.

Benefits:
  Possible multiple graphics display support.

How:
  Once a viewer has been opened in a new window, anything opened using that
viewer should be opened in that viewers window. This suggests an extended
Filer_OpenDir message which specifies which window to open the new viewer
in.

Costs:
  1 week.


*  Don't generate error on !Boot failure

Looks:
  If a !Boot execution fails then no error box should be displayed.

Benefits:
  Fewer errors when opening Net viewers to which the user has no access.
This may be thought of as a hinderance, rather than a help.

How:
  There must be a new command written which which just throws an error away
or stores it for a given command. This command would be generally useful,
not only to Filer. Once this command has been written (the techknowledgy is
well understood from work with the Obey command) the Filer's task becomes
trivial. All it has to do is use this new command when doing !Boots. It can
detect a generated error, and note that that application hasn't been
successfully booted.

Costs:
  1 week (including the new command being written).


*  Hidden files in directories.
*  Directory viewer protection.
*  Content protection.
*  Display protection status

Looks:
  For individual directory viewers certain operations would be disabled.
Such operations as copying into/out of the viewers or deleting items in it
would be amoungst the ones controlable.

Benefits:
  In the classroom environment this would give the teacher greater control
over a file server and the mess which students can make of its organisation.

How:
  In a directory, a new file, !DirSpec (or some such) would be added. This
would be a human-readable file which controls the features of the given
directory. This file would be line based, each line being one command. The
commands would be:
Hide <filename>         Hides the given object from being viewed.
DontCopyOut             Stops copying from this directory.
DontChange              Stops changes being activated in this directory.
                                Copying into this directory is stopped too.
DontOpenApps            Stops applications being opened as directories.
                                Apps are not passed to Find operations.
<anything else>         Ignored - to be used for commenting and layout.
This scheme isn't total proof against meddling, but it stops the idle or
novice user making a mess where it isn't wanted.
  To implement this, a few extra status bits are needed - one for each file
indicating whether it is hidden or not, and 3 for the directory indicating
DontCopyOut, DontChange and DontOpenApps. I am not even sure that
DontOpenApps is needed.

Costs:
  2 weeks.


*  Abortable/background filer_opendirs

Looks:
  When the Filer is opening a directory viewer the user would be able to
curtail the execution of !Boots. Also the execution of !Boots would happen
in the background.

Benefits:
  Less user frustration. If an applications directory viewer is openned and
the user has no access to it, then the user gets frustrated at not being
able to stop the doomed directory openning. This would cease to be a
problem. With background filer_opendirs the desktop would remain alive
whilst the opendir was happening.

How:
  Due to the problem of escape-pressing being not well defined in the
desktop, I would class its detection as being in the 'Impossible' class of
features. On the other hand, given that !Boots won't produce errors
(assumption about new feature being implemented), all that needs doing is
for Wimp_Poll to be called between each !Boot. This requires the separation
of application booting from directory recaching, to be moved to being a
background operation running when the Filer receives a NULL event. As
application booting is already half split out for the Filer_Boot command,
finishing the process should not be too difficult. A new bit would have to
be allocated to each object stored in a directory which means 'Needs booting
in background'. A global count of these would enable NULL event capturing to
be turned off once the process is finished.

Costs:
  1 week.


*  Arrange vertically/horizantally option

Looks:
  As a new Display=> option the user could select sorting to be on a row by
row basis or column by column basis. The *Filer_OpenDir command would have
to be extended to cope with this. The arrangement would determine whether
the scroll bar was on the window's side or bottom.

Benefits:
  The user would be given greater flexibility in arrangement of files and
would enable easier finding of files in a viewer.

How:
  An extra bit would have to be stored internally for the arrange mode and
the viewer display and item select code would have to be heavily changed to
cope with the rearrangements.

Costs:
  2 weeks.


*  Deselect only once file has been read.

Looks:
  Whilst a background copy operation is happening the files being copied
would only be deselected in the viewer once each one had been successfully
read. If the user changed the selection whilst the operation was in
progress, then the selection would no longer change as the files were read.

Benefits:
  This would strengthen the multi-tasking feel of the RISC OS desktop and
would enable the user to continue a failed copy operation from where it had
left off.

How:
  The background copy operation would have to send messages to the Filer
informing it of the reading of files. Filer_Action would have to give a
cycle number so that two copy operations wouldn't clash. The Filer would
supply this cycle number and maintain it internally, increasing it when the
selection was changed by the user. To transfer the information Wimp messages
should be used.

Costs:
  1 week.


*  Confirm close on Filer Action window

Looks:
  Once a Filer_Action operation had finished it would wait for the user to
click on an OK box.

Benefits:
  The user gets to know about all background operations which finish.

Costs:
  3 days.


*  Invalidate only those files which have changed etc etc.

Looks:
  When directory viewers get updated on those areas which have changed would
be redrawn. When recaching information inside directory viewers, only those
files which have changed have their information re-read.

Benefits:
  The desktop runs faster and with less flicker in the directory viewers.

How:
  At the moment, the Filer re-reads all the contents of a viewer in which
one object has changed. A more specific 'This object in the viewer has
changed' flag would have to be given to every object in a viewer. The window
invalidating would have to be more specific once a viewer was recached.
Flags in the object information 'Needs recaching' and 'Needs redisplaying'
should be present. A flag in the directory's information 'Needs some
recaching' should be present to speed things up.

Costs:
  2 weeks.


*  Write out of already-read files on aborted copy operation.

Looks:
  When a copy operation is aborted and there some completely-read files
which havn't been written then the copy operation should go into confirm
mode. Each completely read file in memory would be confirmed for before
being written. Clicking on Abort would now totally abort the operation.

Benefits:
  Less user confussion. When the user aborts she is expecting the operation
to have completely copied all files up to the one whose name is displayed.
This is not the case due to the large degree of buffering that Filer_Action
does. If she is prompted for the bits that havn't been written yet, then it
will be obvious what is happening.

How:
  Filer_Action would have to identify the situation and change mode
appropriately. This is not hard, as it is constructed for such mode changes
to occur. The files to read sequence would have to be terminated forcefully
and the process switched to a special confirmed writing which checked each
completely read file.

Costs:
  1 week.


*  More reliable viewer update.
*  Filename=>canonical filename mapping (used, rather than implemented).

Looks:
  The directory viewers would be updated perfectly when files change.

Benefits:
  Less user irritation and a better name for Acorn. Each mis-feature (such
as incomplete viewer updating) can cost a little in bad press.

How:
  When an UpCall_ModifyingFile is received by the Filer, it would have to
call the system to change the given name to a canonical name. Once it has
that the process of invalidaing and recaching viewers continues as
currently.

Costs:
  2 days (for the Filer).


*  Filename=>operations doable on that file.

Looks:
  Only those operation which can be performed on a given file would be
enabled in the menus.

Benefits:
  Less user confussion. When the user clicks on an enabled operation it
happens without errors more often.

How:
  A system call to find out what can be done to a given object must be
implemented for the Filer to be able to do this. Once this has been done the
Filer has to disable impossible operation on the selected object. When
enabling the relevant menu oprations the Filer would call the OS first to
find out what can be done to this object (this is only meaningful when one
file is selected), and disable all entries not allowed.

Costs:
  1 week (for the Filer).


*  Unpended SWI call use.

Looks:
  Smoother desktop use. When background operations are happening the desktop
is much smoother to use.

Benefits:
  Pleasanter to use desktop.

How:
  This very much depends on how unpended SWIs are implemented. Assuming the
file SWIs are implemented on the call me, then try again later if it
returned with an incomplete answer, then Filer_Action should use these
alternative calls, doing Wimp_Polls whilst waiting for the SWI to finish.
Due to the structure of Filer_Action this is easy (it already Wimp_Polls
between blocks).

Costs:
  1 week (for the Filer).


*  Shared Filer-style window support.

Looks:
  All viewer-type windows work the same.

Benefits:
  Less people re-implement the same functionality (viewer handling).

How:
  Extract and export the essentials of viewer handling. This is a major
hatchet job on the internals of the Filer as the essence of the viewer is
bound in quite tightly with being a directory viewer. Also, the control
template for the Filer contains controls for the viewer and the elements
within it, which aren't part of being a viewer. It should be possible to
seperate the two elements - viewerness and directoryviewerness, but it will
involve quite a bit of work.

Costs:
  3-4 weeks.


*  Open dir without boot file execution.

Looks:
  With a suitable shift-alt-control-f12-click (or something) a viewer would
be opened without application !Boots happening. This would cause those
applications to be displayed with the App icon, not their own icon.

Benefits:
  Quicker viewer openning and this would allow the user to circumvent some
nasty person who runs things in the !Boot file (eg !Wanda)

How:
  Filer must recognise the key sequence and not boot applications. This
should be quite simple as code simply requires skipping at the right time.

Costs:
  3 days.


*  Boot file valid command limits.

Looks:
  Only a limited set of commands would be executable within application
!Boots.

Benefits:
  Restrict the number of silly mistakes possible in !Boot files. This is probably
not a desirable feature.

How:
  OS must allow commands to be disabled (method TBA) or Filer must
re-implement Obey and OS_CLI and parse the !Boot file itself.

Costs:
  4 weeks.


*  !DirSpec - tunable directory layouts.

Looks:
  Files in a directory would be moveable about. Thus the layout of files in
a viewer would be alterable.

Benefits:
  The 'Why can't we rearrange the files in a directory as we want' camp
would be silenced.

How:
  Complete rewrite of viewer handling (probably in C).

Costs:
  4 weeks.


*  Settype presents a list.

Looks:
  File=>Settype would present a list of types as well as a text field.

Benefits:
  The user would choose the type by icon, rather than name and wouldn't
have to remember the type's name either.

How:
  Construct the settype menu by enumerating the file type system variables.
This is fairly simple - allocate a quantity of RAM and fill it in as one
enuerate the file types.

Costs:
  1 week.


*  Confirm on dirs before files.

Looks:
  With confirm ON directories would be confirmed before their contents. If a
No is selected, then the directory's contents are skipped.

Benefits:
  Satisfy users who keep wanting all these extra features.

How:
  Extra flow control in Filer_Action.

Costs:
  2 days.


*  Configurable menus.
*  Moving menus about

Looks:
  The user would be able to change the menus to her requirements by editing
a menu control file.

Benefits:
  Unwanted facilities could be removed; bad arrangements to be made good for
ergonomic reasons.

How:
  Method (a): Implement a system of menu controls specific to the Filer.
  Method (b): Re-write the Filer in C and use o.ctl which already performs
all of what this feature needs.

Costs:
  Method (a): 4 weeks
  Method (b): (re-write) 8 weeks


*  Rewrite in C.
*  32-bit PC Support.

Looks:
  No change.

Benefits:
  Would work with 32-bit PCs.

How:
  Rewrite in C.

Costs:
  8 weeks.
