From: nas20@cl.cam.ac.uk (Nick Smith)
Subject: Sprite dragging/New Filer/Replacement ToolSprites
Summary: Forcing sprite dragging in filer, replacement sprite & toolsets + related topics (!)
Keywords: sprites dragging filer RISCOS
Reply-To: nas20@phx.cam.ac.uk (Nick Smith)
Organization: U of Cambridge Comp Lab, UK
Date: Wed, 11 Nov 1992 16:13:38 GMT

This post puts forth my ideas about Sprite dragging, an improved version
of the RISC OS 3.10 filer, and a few related topics (toolsprites & replacement
file/application sprites). It is rather long and rambles in places - you
have been warned ! Follow ups to c.s.a.tech *only*, or email please.
---

There has been a lot of discussion over the last month or so in comp.sys.acorn
and comp.sys.acorn.tech about real sprite dragging - specifically the 
DragASprite module present in the RO3.00/3.10 ROM that allows applications
that are aware of it, to use DragASprite_ SWI calls to solid-drag their
icons from saveas dialogue boxes instead of using Wimp_DragBox and getting
a rotating outline box.

Once c.s.a had agreed that using *FX 162,28,3 was *not* the way to turn on
dragging, and that you should toggle a single bit in CMOS using something 
like ;

   REM Toggle state of DragASprite bit in CMOS
   REM From: mhardy@acorn.co.uk (Michael Hardy)

   REM Read byte
   SYS "OS_Byte",161,&1C TO ,,byte%
   REM EOR byte with mask for bit 1
   byte% = byte% EOR 1<<1
   REM Write byte back again
   SYS "OS_Byte",162,&1C,byte%
   END

the discussion moved on to more interesting things - like "why doesn't the
filer solid drag its icons?", and "maybe we should do something about it".
(I am summarising a month of discussion for those who haven't (or can't) 
follow the various threads in c.s.a and c.s.a.t)

I wrote the RISC User module 'ForceADrag' module (back in January!) which
forces all RO2 and RO3 applications to use the DragAsprite module by
intercepting the SWI vector, and turning Wimp_DragBox into DragASprite_
calls. This is no substitute for correctly written RO3 applications (like
the Acorn ROM apps), but is useful if you like solid drags while you wait
for everyone to upgrade their software ...

I have done a new version of this module which patches the RO3.10 'Filer'
module and makes it use solid drags for dragging *single* files about
the place (the old version does not do this, because the Filer directly
plots its icons with Wimp_PlotIcon, rather than storing them as icons
in the window definition, which results in you not knowing the name
of the sprite you want to drag unless you patch the filer directly)

At the same time, Andrew Hersee <ahersee@uk.ac.warwick.dcs> has also
done a patched filer module which lets you define a sprite for that
directory (ala !app) rather than using the sprite 'directory' for
all of them.

What I propose is the following:

A joint piece of PD software, between myself, Andrew and anyone else
who wants to help (full source distributed) which ;

 * Forces all RO2 & RO3 apps to use DragASprite SWIs (also *Configure
    SpriteDragging command to stop all the confusion with *FX's, etc!)

 * Lets you drag single files around with the Filer module as solid 
    drags. Patches the RO3.10 filer module *only*, using something
    like !Patch, and so you must load the patched filer module into
    RAM. It is only 26kb or so. It has to be patched, rather than
    distributing the new filer module because of Acorn's copyright.
    In fact it may be breaking the license to *RMFaster the module
    and 'copy' it into RAM 8-)

 * Lets you drag a selection of files around the filer using either
    a) user definable sprite, b) sprite that bears some relation to
    the filetypes dragged, or c) outline box as normal - all
    configured by the user for a flame-free application ;-)

 * Lets you define sprites (and sprites22) files for inside directories

 * A set of replacement sprites (Resources:$.Resources.Wimp.Sprites)
   See below for more details.

 * A set of toolsprites for 3D desktop, with a little app to switch
   these on/off, etc.

Possiblities that require more work ;

 * A Filer which *displays* longer filenames (eg, upto 16 chars long)

   NOTE: This is very different to a replacement FileCore which lets
   ADFS, etc. actually *have* filenames longer than 10 chars ! 
   However, we now have FS's like MemFS, SparkFS, NFS, etc. which 
   give us filing systems that can handle longer names.

   The mechanism I suggest for this is small/large icon displays 
   which are staggered vertically (ala !Sticky), and a user 
   definable full info mode which uses an environment variable to 
   determine how the info appears (eg, 16 chars names on the right
   of the window, rather than the left)

 * A new version of DragASprite (written from scratch) which works
   better than Acorn's (which is a little buggy!)

Sprite/Tool sets

A similar discussion has gone on about why Acorn hasn't gone '3D'
etc in RO3.10 - basically they have given the user the choice
of going 3D if they want - you can replace all the sprites for
standard file/app icons, and you can define your own window border
set & load them in via *ToolSprites.

I would love to see a wave of sprite/tool set construction going on
now more people have RO3.10, and then a vote for an 'official' 
comp.sys.acorn set 8-) The comp.sys.acorn.advocacy group will be kept
busy for months !! This set could be distributed along with all the
'failures' with the new filer patch/etc software.

I hope we can have some useful discussion about the above items - 
I welcome all comments via email & news - but please post replies
to comp.sys.acorn.tech, rather than comp.sys.acorn to allow those
who can't read c.s.a (eg, SJ-Research people) Also I don't read 
comp.sys.acorn.advocacy, so don't be surprised if I don't respond
to anything posted there !
--
Nick Smith, Rm.226, Churchill College, Cambridge ! Email: nas20@uk.ac.cam.phx
.sig quote wanted - must be under guarantee.     ! Tel: (0223) 465596
Newsgroups: comp.sys.acorn