An examination of RISC OS "Desktop settings"
This page last updated: 19 Feb 2018
RISC OS and Desktop Settings
Don’t be tempted to save Desktop Settings from the Task Manager. It can lead to pain and discomfort
On the RISC OS desktop, the right-most icon on the iconbar is usually the Task Manager. Amongst other things, it allows you to save what it calls the ‘Desktop Settings’ either from the Task Manager iconbar menu or from the menu in the Tasks display which you can open by Select-clicking its iconbar-icon. RISC OS 5.18 by default saves such a file as <Choices$Write>.Boot.Tasks.!Boot which will be run by the operating system during a boot, obviously, starting at the next one.
You may be shocked to learn that received wisdom is not to use this mechanism if you can avoid it and you can. An indication of it being discouraged is that later versions of RISC OS from ROOL have it removed from the iconbar menu. It is there for access to the information it contains from the Tasks display menu, but please don’t use it to save a file which is executed during the boot sequence. Don’t be tempted. It is better to keep the settings you want for the boot sequence within the Configure framework, which saves its various settings files in all the right places. I recommend you keep the default Desktop settings !Boot file EMPTY and LOCKED to STOP YOU using it! There: I have saved you from every wasting any time de-bugging a Desktop Settings file. It is a legacy, superceded, ancient, hung-over, partial-solution mechanism from the RISC OS past we don’t like to talk about any more. Perhaps from when RISC OS 1 was called Arthur and he had a steed called Zarch. (Now cloned for a PC near you as Z-Virus - oh, the memories!)
By default, the Desktop Settings !Boot file duplicates actions and settings set up and stored elsewhere and contains things you may not want included at the next Boot(!). It can give rise to…guess what? Problems with booting the machine! Some things can end up being loaded twice if you take your eye off the ball (cue Usenet threads: my boot is broken!). Any duplication obviously also makes the process of boot slower than it could otherwise be. Okay, not by much, I admit, but its having to de-bug the inevitable problems caused if you save Desktop Settings and have some of those same commands elsewhere in the boot sequence..
I have been looking at a Desktop Settings file I could save right now from my Task Manager. There is nothing which has not appeared thanks to configured settings, Organizer, or things I have done in this session. If I saved the settings file, most of that stuff would be duplicated in configure’s choices and the remainder I may not want open until the right time. I definitely do not want to use half of the Configure > Boot options (Run and Look at) only to see them duplicated in the Desktop Settings file I have saved. What would be the point? Some other entries reflect the fact that the OS scans the Resources directory at boot, and you can't easily turn that off without re-writing the OS. All those Filer_Boot commands will be duplicated at the next Boot, wasting time. So, you could use one mechanism or the other and not both: you have to accept that some actions will be duplicated unless you have the time to waste manually editing guff, or simply expect boot to be slower than it needs to be. But you are going to use the remainder of Configure of course? Then why not use all of it? I would argue that it is less confusing to make changes in Configure than to hand-edit a file which it is too easy to overwrite with a careless click on an OK button in an easily accessed menu option. So, please disregard the Desktop Settings !Boot file altogeter. Blank it and Lock it.
The Desktop Settings file you can save from the Task Manager is more like a log of the apps which have been run in the desktop (and not quit) during or since the last boot with a note of the filer windows which are open, plus some other variables which have been set. It is a snapshot of your desktop now perhaps but probably not a list of commands you want to see executed at the next Boot. You could have lots of apps installed in the iconbar which you only use infrequently and don't want there every time you switch on. However, if you want to reinstate the filer window positions, this seems to be the only source for that particular information: the Filer_OpenDir commands are easily extracted to an Obey file, or left to be the only thing remaining in the so-called Desktop !Boot file. You should only use the Desktop Settings at Boot if you really understand the implications of what you are doing and in that case it may be wise never to add anything to ‘Look at’ or ‘Run’ in Configure > Boot. The important thing to consider is that using Configure 'properly' means that the Desktop Settings !Boot file is redundant, whereas using a Desktop Settings !Boot does not preclude the use of Configure. The Desktop Settings are pretty much a limited sub-set of Configure and can be rendered completely pointless by the correct use of Configure.
I thought ‘right now’ would provide a random example with exceptions but there is NOTHING in a Desktop file I could save right now which is worthy of saving for the next Boot. ALL of it duplicates apps being run etc., which is done elsewhere in the boot sequence or is something I wouldn’t want run at boot but maybe when Organizer next runs them, or when I do. A Desktop Settings file would perform too many tasks; far more than I require at the next boot.
Applications which you want run or seen at boot should be included in Configure.. > Boot. Once you do that, there is no real reason to use the desktop settings file at all unless you want filer window positions restored in which case edit the file or everything else may be done twice. If nothing else, many of the apps you place in Run could be kept in alphabetical order, making them easy to find, rather than them being in the higgledy-piggledy order they were run and sprinkled amongst the irrelevant dross in a Desktop Settings file.
Until such time as ROOL's strand of RISC OS provides the ability temporarily to disable a Run entry when de-bugging, we have unfortunately to remove and replace things when debugging boot. However, if you don't use the Desktop Settings file, the need for debugging your boot sequence will be reduced. I can almost guarantee that.
Starting out with a Sinclair ZX81, the author switched to Acorn and has owned the BBC Model B and progressed to Archimedes, RiscPC and then a Castle Iyonix and A Raspberry Pi on standby. He has written a few simple utilities for RISC OS and is currently using it to develop web sites and he likes to dabble in graphic design. Over the decades, he has also progressed from a DOS environment through to Windows7-64. He says it's nearly as good as RISC OS!