Where do we discuss issues with Direct

that setting is written to the PreDesktop file

Which means that the association between the app and its files will already exist by the time the desktop appears, so you can just click on a file and the appropriate app will start without you having to go looking for the app.

It seems like a backward step to be forcing users to keep apps in a particular place, and pop up errors when they try to move them, unless there’s a very good reason.

In this instance the App appears to have been installed in a specific location and whether that was the install program that did it, or the user at some time in the past, is pretty much irrelevant – it’s locked in place.

That being the case the user can then do the Add to Apps and the soft link pretends the software is in the Apps folder. No one actually goes through the files and folders to open $.Apps do they?

As Steve¹ said of Apps and general applications “It’s a place for them” and as I pointed out a-n-other-location called whatever the user wants is equally good since you can “Add to Apps” any applications at any location that is visible to the system at the time the Add to Apps element of the boot sequence occurs.

Add to Apps is supporting a situation that is actually the exact opposite of dictating where the application has to be.
In my case I deliberately put SparkFS (read/write) in a directory that isn’t part of the normal HD4 installation to ensure against accidental overwrite with the read only version. I can see other people having equally valid reasons for not using Apps or any other HD4 created location.

¹ That’s the other Steve (or one of the others). I’m me, and the others aren’t. :)

It seems like a backward step to be forcing users to keep apps in a particular place

As one of the Steves said, the system has been told the app “is there” and then it isn’t. You’re free to put apps wherever you like, but expect the system to sulk if you don’t update that bit after moving the app. ;-)

No one actually goes through the files and folders to open $.Apps do they?

Yes. Somewhat less these days, thanks to another Steve’s AppUtils permitting directories in the Apps virtual device. However, there’s a lot of stuff in $.Apps in subdirectories. $.Apps.Emulation, $.Apps.Misc, $.Apps.Utilities, blah blah.

to ensure against accidental overwrite with the read only version.

I Locked mine. And inside it is a zip containing itself (just in case!).

After the show, I’ll go over this with a fine tooth comb. Like others, I’d have expected this to fail quietly, and without error. The fact it doesn’t worries me, but I need to investigate on more than one platform to see what’s going on.

As many of you know, I didn’t create the original disc image. I assume that programs were added via “Add to Apps” as David Pitt mentions. I don’t recall such files going in PreDesktop, but it is quite possible – it is a long time since I actually checked that. Thinking about it, yes, Add to Apps would probably be in PreDesktop, whilst “look at” would be in Desktop. I can see that logic. But whether that’s what happened will remain to be seen. Like I said, it needs investigation.

To be honest, there’s no reason why direct would be different to any other build of RISC OS in this regard – it is simply making sure that the bundled apps have been seen, or added to Apps, during startup. The only difference is that other versions of RISC OS may not ship with bundled software, or that software may not be being seen/added to apps during startup.

Either way, it needs a full investigation. I couldn’t see anything immediately obvious in that 15 mins I spent earlier today, but that may just mean I wasn’t looking hard enough. Needless to say I’m rushed off my feet this week.

I don’t recall such files going in PreDesktop, but it is quite possible

Line of text in the Predesktop file. The directory that holds files in that area is “Predesk”

Thinking about it, yes, Add to Apps would probably be in PreDesktop, whilst “look at” would be in Desktop.

That is how RISC OS 5 does it but at some point Select does move Add to Apps into Desktop.

It is not a huge problem in this instance, simply delete the non RISC OS 5 compliant BootApps section from the Desktop file and reset with the RISC OS 5 Add to Apps Configuration tool.

HTH.

P.S. I could almost think that some of the Direct disc image was created on something other than RISC OS 5.

Don’t think so David P – it wasn’t me who did it, but AFAIK everyone involved was running OS5. It is true that I use a mixture, but by its nature, Direct was created for Pi, and I doubt those files were done by hand, and doubly doubtful that they would have been done on adjust! Anyway, thanks for the feedback :)

I suspect those changes won’t happen in the mini-update, because I’m very cautious about re-writing/over-writing peoples’ boot files (Destkop, PreDesktop) in “drop on” updates unless absolutely necessary. I think this is a change better made in the larger update before Christmas, and in the complete download image.

I could almost think that some of the Direct disc image was created on something other than RISC OS 5.

Don’t think so David P – it wasn’t me who did it, but AFAIK everyone involved was running OS5. It is true that I use a mixture, but by its nature, Direct was created for Pi, and I doubt those files were done by hand, and doubly doubtful that they would have been done on adjust!

I’m going to stand my ground on this with just a little tweak.

I could almost think that some of the Direct disc image was created on something other than vanilla RISC OS 5.

How about this. The original author was running RISC OS 5 with some Select features, specifically the Boot configuration tool. That tool from the A9home does produce a three line entry, including the BootError, for each item Added to Apps and saves to the Desktop file. (The vanilla RISC OS 5 tool produces only two lines, and no BootError, into PreDesktop.)

I can’t prove this as this Select feature requires ROL toolbox modules which crash on OS5.

P.S. I have however managed to persuade this Select feature to run on RPCEmu Direct and the Add to Apps greyed out in RISC OS 5 are now not and new entries do go into the DeskTop file.

Not that it matters that much, the BootError issue is understood now, but there might just be something interesting going on.

From RPCEmu forum:

I am trying to go through and improve things where possible, and constructive feedback is very helpful.

You need minions to test and suggest improvements – oh, that’s us… :)

The next update will be a “drop on top” small one which adds Pi4 compatibility and fixes a number of issues that I have encountered and had reported.

Since the “Manuals” link in $.Programming is just a Filer command to open the Manuals directory a quick and dirty (or possibly the long term) would be to put a link similar file in the directory alongside GCC to open the examples (and another to open the !Help?)

I can’t prove this as this Select feature requires ROL toolbox modules which crash on OS5.

P.S. I have however managed to persuade this Select feature to run on RPCEmu Direct and the Add to Apps greyed out in RISC OS 5 are now not and new entries do go into the DeskTop file.

Logical run through on that is that the build (or at least that particular bit) was done on a different hardware platform (early Pi with exceptions settings?) so the Select toolbox tool didn’t crash.

There is no BootError command or file, I think it is a ROL-ism.

The Select only command BootError turns out to simply write the error to be reported to the Boot log.

*fx0
RISC OS 4.39 (28 Apr 2004) [Kernel 6.80]
*help BootError
==> Help on keyword BootError (alias)
*BootError is an aliased command.
Expansion: SetEval Boot$ErrorCount Boot$ErrorCount + 1|MSysLog Boot 80 %*0|M
*

The Select only command BootError turns out to simply write the error to be reported to the Boot log

Just logging? No error recovery so the boot completes as much as possible?

Well, either way, thankyou David for getting to the bottom of things. It remains a mystery because AFAIK of the three other people involved, I’m the only one who makes any real use of Adjust, and I was the one who was too busy to be involved in building Direct!

Anyway, terrific detective work, thankyou. When we issue a full build download, it’ll be sorted.

When we issue a full build download, it’ll be sorted.

Just a last thought, if a temporary drop-over RPi4 update is in prospect then deleting all of the seven BootError lines in the Desktop file and dropping that should do. The AddApps command works in either PreDesktop or Desktop. The only downside is that, as now, these ‘adds’ are greyed out in the RO5 configuration tool.