Hi and Questions..

Hi people! :)

It’s great to have an opportunity to “muck-about” with RISC OS again (using a Raspberry Pi).
Having been part of a primary school where every classroom was kitted out with Acorn machines and (BBC ’B’s too) I’ve enjoyed getting to know the OS again.

I am however stuck with a couple of problems.
I have seen out there on the great interwebs; screenshots of systems with blue folder (shortcuts – I think, correct me if I’m wrong) placed in the left side of the icon bar next to all other Disc & Hardware type icons. I can’t seem to find a way to do this as draggy droppy just causes the directory to be opened by Filer and there doesn’t appear to be anything hidden in the menus.

An example I’ve found is this:
http://www.wrocc.org.uk/riscos/images/desktop.jpg
A bit Lo-Res but hopefully this helps to explain.

Lastly, why don’t folders show in Resources:$.Apps?
Using Packman I have installed a couple of applications and fetched a few others from the wild (namely !TapirMail) but they never show in Resources:$.Apps as they have been foldered into categories by !PackMan. I’m a bit hesitant to move them from their installed locations so as to maintain !PackMan’s handy update and uninstall.
But items I have copied directly into SDFS::RISCOSpi.$.Apps (or at least they do upon reboot – refreshing doesn’t appear to do anything on that directory) show up.

Thanks in Advance

Craig

You’re looking for !Transient:

Transient is a utility which provides a temporary directory on your hard
disc, creating a new subdirectory every day to help you organise files.
You can use it like a RAM disc – drag files to it, save files to it –
but the files will remain on the hard disc until you delete them.
If so desired, the directories can be expired automatically when they’ve
reached a certain age.

http://www.stronged.iconbar.com/fjg/zips/

Oh and welcome back ;-)

Lastly, why don’t folders show in Resources:$.Apps?

You almost certainly want to add the apps in the folder to the boot sequence config – d-click on the !Configure (upper/mid left of the default screen setup), click on Boot (top left) and then ‘Add to Apps’ (leftmost). You’ll see a list of files and folders under the heading ‘Add to the Apps folder’. Just drag in your folder and the hit ‘set’ (bottom right), then the ‘set’ in the ‘boot sequence’ window, then close the Configuration window. Next time you boot, the contents of the folder(s) you added will appear (as if by magic – magic I tells you!) in the apps doohickey.

Lastly, why don’t folders show in Resources:$.Apps?

They may, but because ResourceFS is not a true filing system and does not support the concept of folders/directories they are not quite what they seem, despite what can appear in the display.

First, this is briefly how applications are added to the Apps directory:

You add an app to the Apps folder either discretely by using the *AddApp command or implicitly by using the Configure Add to Apps dialogue, which does this for you. This creates “!Boot” and “!Help” Obey files in ResourceFS to *Filer_Run the “!Boot” and “!Help” files in the true application directory on disc. If either of these true files are not present, an Obey file is not created. It also creates an Obey “!Run” file to *Run the true directory, which usually runs the application.

Second, this is how ResourceFS deals with the added files:

The Obey files added by AddApps are given a name that starts with “Apps.”, eg “Apps.” + “!MyApp.” + “!Boot” ¹. This is not a path – note that there is no file system or root directory. It is the Resources Filer that interprets this name as if it were a path, displays directories and runs files as you would expect. If you open the menu from the Apps icon and click “Open $” you can explore lots of apparently heirachical directories.

The rom-resident apps and apps added other than by *AddApp are different and are constructed from files added to ResourceFS, mostly from modules. These may have names that can be interpreted as directories containing applications.

¹ ******* textile gets in the way with plings.

Thankyou very much people for the suggestions and helping me out.

@Steve Drain – Ah, that helps, I remember doing that (clicking ‘Open $’ menu on Apps) when I was younger and not quite understanding what I was looking at.

@DavidS – AddTinyDir did the trick! Even managed to get it to recur on reboot by writing an Obey file with the one statement and adding it via !Boot Configure applet. :D

@patric aristide – I will keep !Transient in mind, seems like a great way to handling a Downloads folder.

Thanks again people, much appreciated.

Second, this is how ResourceFS deals with the added files

And of course it’s pretty simple to write a module that will load a specified file into memory and register it with ResourceFS with a given name, which can contain as many subdirectories as you desire.

Come on, we’ve all done it. ;-D

Also worth a mention that AddTinyDir also went a long way to answering one of my long standing questions – how can I get an icon on the icon bar to point to a Fat32 filesystem? I just updated the wiki with a short obey file that will mount a Fat32 filesystem, and use AddTinyDir to pop a folder onto the iconbar. Perfect. Thanks :)

how can I get an icon on the icon bar to point to a Fat32 filesystem?

Er! If you can’t get an icon on the icon bar to point to a FAT32 filesystem, it sounds as if something’s gone rather seriously wrong! RISC OS very much does have support for mounting FAT32 drives and adding them to the icon bar, either natively via DOSFS or (recommended) with Fat32Fs. What kind of drive were you attempting to plug in?

Yup – it’s the ‘spare’ 2GB on my SD card, formatted as Fat32. So how would I add an icon to the icon bar using Fat32FS for this filesystem? I had a quick rummage through the documentation of Fat32FS but other than the ‘f’ flag that opens a filer window, I didn’t see similar option to plonk an icon down on the icon bar.

which can contain as many subdirectories as you desire.

Up to a total of 63 characters, if that limit still applies – I do not think it is documented in the PRM. Of passing interest is that the Resources Filer would deal with long filenames well before they were available in general.

Come on, we’ve all done it. ;-D

But have we done it ‘properly’? The ResourceFS (RFS) module has a service call to say when it is (re-)starting. You are supposed to monitor this and re-register files. When I was writing my RFSFiles ¹ module many years back, I ensured that this was done, but I soon realised that very many other users of RFS were not. A common use of RFS is for Messages files, and not complying with the protocol would easily crash MessageTrans among other things. Because compliance was not universal, I have not done it myself with anything I have written for a long time. This does not seem to be a problem, but I feel a bit bad about it.

¹ RFSFiles allows any file to be registered and deregistered with RFS without having to write a special module, using *commands or SWIs. It is 32-bit and Pi compatible.

not complying with the protocol would easily crash MessageTrans

Looking at the computer in a funny way was usually enough to crash MessageTrans.

Whoever thought of relying on a linked list of client-allocated blocks (which therefore stuff up ALL apps if one freed its block but forgot to deregister), needs a very hard slap.

Later versions copied them at least, but for a while there… I have a *MsgTrans utility in my library that fixes up the list. It happened that often.

Looking at the computer in a funny way was usually enough to crash MessageTrans.

;-)

With RFSFiles I did some odd things about ‘intialising’ some files, which are probably best ignored now. One of these was Messages, which I realised did not actually need to be opened in the official way to be used with MessageTrans_Lookup etc. They did not get linked into the list.