Boot / Run at Startup - back to the original topic

I’ve just checked in a new version of the configure plugins for !BootSetup – ie “Add to Apps”, “Look at” and “Run”.

This update adds a resize icon to the window – resizing the window also resizes the list. Feedback to this thread please.

Note that these are disc image components, not part of the ROM. I’m not sure how often the disc image gets rebuilt. The relevant applications in the disc image are:

!Boot.RO500Hook.Res.Configure.!BootSetup.!BootApps
!Boot.RO500Hook.Res.Configure.!BootSetup.!BootBoot
!Boot.RO500Hook.Res.Configure.!BootSetup.!BootRun

You only need to replace these applications to get the new version.

I’m not sure how often the disc image gets rebuilt.

Technically daily, but I think Steve took the disc image build out of the rotation due to some issues with Perl that we still need to resolve.

Certainly the most recent image on the download page is dated 23/10/2012. It’s a bit of a waste of bandwidth to download a 15 meg file just to get three plugins, too.

When I get myself some new web space sorted out, I’ll put a temporary build of these plugins up for people to test out.

Another thing: Did you check that the new windows work OK when the plugins are launched in low res modes? (e.g. 640×480)

I’m not sure if you’ve changed the method the plugins use to attach the pane to the main window, but the method it was using previously relied purely on the relative position of the two windows at the time they were saved from the template editor. However when the windows are created at runtime they seem to get shifted to lie fully onscreen before the code is able to set up the pane logic properly – so if the templates were saved with the windows in a position where they won’t fully fit on the screen mode that’s in use at runtime, the windows will get shifted and the pane will no longer be in the right place. At the time I took the easy way out and fixed it by shifting the windows to the left a bit in the templates, but a more reliable fix (just hardcode the pane offset within the sources?) would be preferable.

the method it was using previously relied purely on the relative position of the two windows at the time they were saved from the template editor.

That’s always been shonky, and once upon a time Acorn used to ship !Madness which helpfully exposed pane problems.

At the time I took the easy way out and fixed it by shifting the windows to the left a bit in the templates, but a more reliable fix (just hardcode the pane offset within the sources?) would be preferable.

The correct idiom relies on the Wimp_OpenWindow call updating the buffer with the actual coordinates used (as opposed to whatever you asked for – it always did, but now it’s official). So (assuming you haven’t embedded the pane within the parent) when asked to open your parent ‘under’ a particular window, you open your pane at that position in the stack with the computed XY offset, then open the parent under the pane at the requested coordinates, but then check the buffer to see if it was actually opened somewhere else and if so, reopen the pane in the correct position (with the same stack position).

Which is slightly less tidy especially when juggling multiple panes, but is robust and works all the way back to RO2.

Quick reply as I’m just about to go out.

The pane position within the parent is now hard coded in the app. Actually it shuffles it to be a fixed distance to the left of the buttons. But the pane is actually a nested window linked to the parent, so it is not explicitly opened by the application on Wimp_EOpenWindow events.

Haven’t checked in low res screen modes, nor does it check the Wimp_OpenWindow results as described above. Both of which I’ll look in to doing soon :)

By the way, can I take this opportunity to highlight a glaring mistake in Bootxxx.c.List? It both reads from and writes to <Choices$Write>. It should be reading from Choices: – and since it’s updating and not creating new files, it shouldn’t be using <Choices$Write> at all, since it doesn’t matter if Choices: has multiple entries.

Currently, the boot plugins crash messily with data aborts if you attempt to start them with <Choices$Write> != Choices: (presumably because whoever made the original mistake felt that, if the Desktop or PreDesktop files were missing, you’ve got bigger problems).

Thanks, I’ll see if I can fix that at the same time. I haven’t touched the actual guts of the app yet, merely the window handling code.

Until the new disc image gets built, you can download a preview here: http://www.squeakysoftware.org/archives/bootxxxx.zip

You might want to back up the apps mentioned in the top post first. Then install the new !Boot from the archive – you can use the !Boot merge tool to do this – and in fact this creates a backup for you.

Rik said

the pane is actually a nested window linked to the parent

Well in that case as I said (“assuming you haven’t embedded the pane within the parent”) you don’t have to worry about the pane positioning shenanigans.

So you did :) Isn’t the nested wimp great :)

By the way, can I take this opportunity to highlight a glaring mistake in Bootxxx.c.List? It both reads from and writes to <Choices$Write>. It should be reading from Choices: – and since it’s updating and not creating new files, it shouldn’t be using <Choices$Write> at all, since it doesn’t matter if Choices: has multiple entries.

I’m not sure if I agree with you there. I know that’s the correct way for applications to access their configuration in Choices, but isn’t the !Boot plugin a special case? Its function is specifically to edit the Desktop and PreDesktop files, which the PRM specifically states must always be accessed via “<Choices$Write>.Boot.Desktop” and “<Choices$Write>.Boot.PreDesktop”. (PRM 5-225, 5-230)

Currently, the boot plugins crash messily with data aborts if you attempt to start them with <Choices$Write> != Choices: (presumably because whoever made the original mistake felt that, if the Desktop or PreDesktop files were missing, you’ve got bigger problems).

The data abort was, I think, due to an error in the way MessageTrans was being called to get an error message – trying to pass a MessagesFD to a swi, instead of a pointer to it! This occurred many times in the code, and each raised a very clear compiler warning! I’ve fixed that, will check in a the new version sometime today.

I’m not sure if I agree with you there. I know that’s the correct way for applications to access their configuration in Choices, but isn’t the !Boot plugin a special case? Its function is specifically to edit the Desktop and PreDesktop files, which the PRM specifically states must always be accessed via “<Choices$Write>.Boot.Desktop” and “<Choices$Write>.Boot.PreDesktop”. (PRM 5-225, 5-230)

The specific case in which it’s failing for me is when running the plugin after Choices$Write has been changed from its original (bootup) value, but the original value is still present in Choices$Path at a lower priority.

I assume (although haven’t checked) that the plugin does an OPENUP, which removes the problem of creating files in paths with multiple entries, and of creating a useless file in a directory which won’t be read on bootup. So it’s a harmless change.

The plugin doesn’t use Choices$Path at all. It reads the current config from <Choices$Write>.Boot.[Pre]Desktop, writes a temporary file in PipeFS, and then uses the installer module (*Install_Merge) to overwrite the original file.

If you change Choices$Write after the machine has booted, there probably won’t be a [Pre]Desktop file in the new location. So there’s nothing for the plugin to edit – and I think it’s sensible in this case for it to exit with a friendly error.

The only alternative I can think of would be for the plugin to act on Boot:Choices.Boot.[Pre]Desktop – on the assumption that you always want to edit the files in your Boot structure – but this is specifically forbidden by the PRMs. Opinions?

I’ll check in a version which has the error report fixed in a mo.

Checked in and also updated http://www.squeakysoftware.org/archives/bootxxxx.zip

The issue at hand here is that the correct location of the desktop file does exist in Choices$Path – but it’s a multiple-entry path, and the post-bootup choices have higher priority.

In my implementation, Choices$Path looks like this: Boot:Choices.,Boot:ChoicesDirs.Username.

Choices$Write is set to: Boot:ChoicesDirs.Username

The file Boot:ChoicesDirs.Username.Boot.PreDesktop doesn’t exist, but the file Boot:Choices.Boot.PreDesktop does. Therefore, reading (and updating) the file Choices:Boot.PreDesktop will choose the latter location and not see the former, this being the entire point of multiple-entry paths.

So as you should be reading from Choices$Path anyway (it’s incorrect to read from Choices$Write), it should transparently update the files in Boot:Choices just like on an ordinary machine.

Since you like to quote the PRMs so much, could you get the part about the correct use of Choices$Path and Choices$Write and Acorn’s own vaguely-defined future plans for a multiple-user system for me?

I’m not trying to be awkward, I just want to understand the problem before implementing a fix that’ll break other things.

The plugin can’t directly update Choices:Boot.[Pre]Desktop because you can’t write to a path with multiple entries.

If it was to act as you suggest (as a normal application should behave, I agree) – read from Choices: and then write to Choices$Write – the effect would be to write the altered [Pre]Desktop file into your user specific directory, while leaving the original in Boot:Choices.Boot.

Is this really the correct behaviour?

I have often thought that writing to a path list should Just Work – ie find if the file exists in the path list and try to overwrite it, or failing that in any earlier paths in the list. Too late now.

If it was to act as you suggest (as a normal application should behave, I agree)

That’s the key point, this isn’t a normal application.

Therefore you should be parsing the path list yourself to simulate the above behaviour – find where the file actually is and save it back there, or earlier in the list. Choices$Write is irrelevant in this case.

OK, or rather than parsing Choices$Path, you could open Choices:Boot.[Pre]Desktop and use OS_Args 7 to find the actual path of the file.

This makes sense, as !Boot.Utils.BootRun actually runs “Choices:Boot.[Pre]Desktop”.

This still means that if someone changes Choices$Path after the machine has booted, you can’t guarantee to be editing the same file that was run at boot time. But I’m more comfortable that this solution won’t cause extra problems.

Checked in and also updated

Any chance you can fix your text editor? It seems to be trimming empty lines on lines you’ve not worked on – it makes reviewing very hard. In that commit, I see only 3 lines which changed, but 7 files were commited!

If you must make none code changes (for example, I find mixed use of tabs and spaces in some of the crusty assembler code round here) at least split into two commits.

OK, or rather than parsing Choices$Path, you could open Choices:Boot.[Pre]Desktop and use OS_Args 7 to find the actual path of the file.

I was proposing the simpler solution of changing what is (I assume from your comments) the equivalent of an OPENOUT into an OPENUP, which does work with multiple-entry paths.

That would have the minor caveat that, if the file shrinks, you’d have to remember to manually trim the extent to its new length. I guess they both have the same effect, so go with whatever one’s easiest. (I just tried to interpret the source to see what it’s actually doing, and it was an impenetrable mess of libraries and secret CLI commands. So you’re better-placed to make that judgement than I am!)

Any chance you can fix your text editor? It seems to be trimming empty lines on lines you’ve not worked on – it makes reviewing very hard. In that commit, I see only 3 lines which changed, but 7 files were commited!

I was proposing the simpler solution of changing what is (I assume from your comments) the equivalent of an OPENOUT into an OPENUP, which does work with multiple-entry paths.

Except that the plugin uses the Installer module, it’s sadly not that simple.

Will have another look at the code later today hopefully.