Kevin Wells has released a new application called Shutdown which, as its name suggests, is designed to do one simple thing: Shut the computer down. When launched, the application presents its icon – a red power button – on the left hand side of the icon bar, with the text “Turn me off” underneath it. A single click on that icon will invoke the standard RISC OS shutdown procedure, with the usual warnings; apps with unsaved data will prompt you to save (or cancel), and so on. As such, the app does exactly what it says on the tin – but not without issues.
The first is a question of the point: The RISC OS shutdown procedure can be easily invoked by pressing Ctrl-Shift-F12, or by clicking the middle (Menu) button over the Switcher icon on the far right of the icon bar, and left (Select) clicking Shutdown on the menu that appears:
With that in mind, what purpose does this application serve? The answer, according to Kevin, is that:
It was designed to be used in a club where only one person knows about RISC OS and what they were doing was turning off the computer by turning it off.
Without actually saying it, he does have a very good point: RISC OS, despite what we regular users like to believe (and often say) is not as intuitive as it could be. For the inexperienced user, it’s far from obvious how to shut the machine down – especially for someone more used to an operating system like Microsoft Windows (which has, um… shall we say “one or two more users than RISC OS”?), for which the equivalent procedure tends to be on the Start menu, which sits on the far left of the task bar (the Microsoft Windows equivalent to the icon bar).
So the application does indeed serve a purpose: For people using RISC OS who are less familiar with it than the rest of us, and who are perhaps used to something else, it presents an easy and, more importantly, obvious way to shut the computer down.
The second issue is Kevin’s choice of location on the icon bar. The left hand side of the icon bar is supposed to be reserved for “devices and resources” (for more information, I’d refer readers to the RISC OS Style Guide, page 92 – but to date, the Style Guide has yet to be published online). I’m not entirely convinced that an app to shut the computer down can claim itself as either a device or a resource – in general, users expect to see things like printers and drives on that side of the icon bar; that’s the sort of thing we mean when we say devices and resources. On the other hand, if the application was positioned on the right hand side of the icon bar, then it’s not supposed to have any text underneath it – but without that text it’s no longer obvious what the application does, and we’re back to the situation where it’s not obvious to an unfamiliar user just how to shut the computer down.
Perhaps a better solution here would be an alternative icon (itself incorporating the text “switch off” or similar), with the icon positioned so that it’s the second from the right on the icon bar, immediately before (to the left of) the RISC OS switcher icon. Since shutting down is the last thing a user will do, it could be argued that it should go to the far right, after the switcher, but users are accustomed to the switcher itself being there so that would not be a good choice – to the left of the switcher icon, therefore, would be much more sensible. By a similar token, while it’s going to the left hand side of the icon bar, if anywhere it should go to the very far left, rather than ending up wherever it’s placed, depending on what other icons have appeared there before it – but my vote would be a change of icon, and positioned next to the switcher icon. Or perhaps the user could be given the choice – left (or far left), or on the right, next to the switcher icon.
The third issue is what happens after the computer is shutdown. Normally, the thing I’d expect to see last, before the computer switches off, is a small window telling me “the computer will switch off in five seconds”, with a “Restart” button that can be clicked – and doing so will cause the computer, unsurprisingly, to restart. However (on my Iyonix, at least), after using Kevin’s Shutdown application, the window still appears, but the button doesn’t respond: the only way to restart the computer is to wait for the it to switch off, and then switch it on again. Since the application isn’t designed for people like me, though, I don’t suppose this is a major issue.
The fourth and final issue, while it can be resolved just as easily as the issue of the application’s icon and position on the icon bar, is a far more serious one that deserves more attention – not just for Kevin and Shutdown, but for RISC OS developers in general. Specifically, Kevin’s little application isn’t the first to be called Shutdown – and nor is it the second. It appears to be the third (that I know of), since there are already two others. The first was written by Thomas Baldwin, but I have been unable to find a working link for it, and the only description of it appears to be that it’s “a handy utility” – so I can’t be certain what it does.
The second, written by Steve Potts, simply runs and does nothing other than wait for a shutdown request. When it receives one, it runs an obey file before it dies – by default that obey file merely plays a sound sample, but it could be altered to do any number of things, such as copy files from the RAM disc to the hard disc, and so on. Clearly, both Kevin’s new application and this one complement one another in terms of what they do – but they really shouldn’t have the same name, which is a clash of resources.
Some clashes are less serious than others – historically, at least – and the seriousness of those clashes may have changed over time. There was a time that two applications sharing the same name, for example, might not generally cause too much of a problem: When software was generally distributed on and run from floppy discs. However, those times are long gone. These days, software is as likely to be downloaded as it is to be supplied on disc, perhaps moreso – and even if it is supplied on a floppy disc or a CD, it’s likely to be installed on a computer’s hard drive, and is therefore sharing its resources with anything else on that hard drive. This is where clashes of this sort can become a problem.
Typically, an application called MyApp will be contained in a special folder (an “application directory”) called !MyApp. It’s likely to have an icon – a sprite – also called !MyApp, and it will normally use at least one system variable, called <MyApp$Dir>. If it saves any user options to disc, this should be in the computer’s standard ‘Choices’ folder, where those options will be saved in a folder called MyApp.
So, when there are two applications called MyApp, at the very least they will both reside in a folder called !MyApp – which means they can’t be saved in the same location, because if you copy a folder called !MyApp to the same location as a folder called !MyApp some files from one will be replaced with some from the other, with the computer’s copy settings determining which.
If one (or both) applications has an icon, that icon will be placed in the system sprite pool for use in filer displays, and probably on the icon bar. With both having the same name, however, whichever one’s icon is loaded last will replace the icon for the other – so in filer displays, both applications will be shown with the icon for one of the two, and the icon bar icon for one might be displayed for the other – as can easily be shown here:
The application on the icon bar is obviously the one from Kevin Wells, since Steve Potts’ application doesn’t present an icon bar icon – but which of the two applications shown in the filer windows is which? They both have the same icon!
So far, though, this naming clash doesn’t cause any serious problems. Sure, the two apps have to be stored apart, and if the icon for one is shown for the other, it might be a bit confusing for the user, but it’s not the end of the world (though counterproductive in the case of Shutdown, given Kevin’s reasons for developing it) – but what about the system variable and choices folder?
The purpose of the <MyApp$Dir> system variable is so that the application knows where it is on disc, once it’s loaded and running in the WIMP environment. It can use that system variable to load files it needs, which are supplied along with it in its application directory – but if there’s another app with the same, that system variable may be changed to point to that app’s location, and if the first app tries to load a file, say <MyApp$Dir>.MyFile then it’s likely to either fail, if the same file doesn’t exist in the other app, or it might load a file with the same name, but containing data it can’t use – and when these things happen, either the first application or the second could go wrong, with how wrong depending on how well they’ve been written.
Then there’s the location of the user’s choices. With both applications using the same name for their choices folder, as well, the risk is that when the user saves his or her choices from one, they could overwrite their choices for the other. When one of the two apps is next run, that means it could potentially be trying to read a choices file for the other – a choices file that contains data it doesn’t understand, and which could therefore cause it to go wrong (again, depending on how well written it is). In this case, how soon this happens depends how often the user runs the application – but when they do and it goes wrong (a badly written app might crash, a well written one might recognise a “corrupt” choices file and simply choose defaults that don’t match what the user expects), they might report it as a bug in that application, on the comp.sys.acorn newsgroups, on a relevant forum or mailing list, or directly to the developer – and it’s entirely possible that that application is not only behaving itself, but that the developer had its resources correctly allocated.
To avoid clashes like this, application names – amongst many other resources – are supposed to be allocated from a central registry. With three “Shutdown” applications all sharing the same name, at least two of their respective developers – if not all three – are guilty of not registering their application names with this service. There was a time when this was probably quite common – and I know I’m guilty of not registering all of mine in the past, for example, but it was when software tended to be distributed and run from floppy discs, so (as I’ve mentioned above) application name clashes were much less of an issue.
In the modern, connected world, there is absolutely no excuse for not doing this – it’s a simple procedure: the “Allocate” application is run, the resource type(s) selected (and, where appropriate, your choice entered), and a file is saved out of the application that can be attached to an email.
The file is sent to firstname.lastname@example.org and you should receive a response within five days telling you either that your requests have been approved (your resources have been allocated to you) or that there is a problem (you’ve requested a resource that has already been allocated to someone else). In the event of a problem you simply modify your choice (change your application name if you are requesting one that has already been allocated to someone else) and try again.