Rainbow Snake (new game - kind of!)

Is it legal to move the settings to a local directory of an applicstion?

Yes, but you’d have to make damn certain that your app does not come with “default settings” that get copied over top of user settings, as nobody will appreciate having their choices and such nuked.
And…….

After decades of listening to the Choices rap and never having a case for moving it to another drive or computer, I have to wonder.

Wonder all you want. Follow the rules and then everybody is happy. You can even run your program from read-only media and have machine local settings from a network shared installation.

Really, the whole Choices thing was a problem solved decades ago.

they often come with the modules they need

Yes, but note that this only works when the resource module is specific to the application. When an app comes with its own copies of system modules, then things get very messy very quickly.

Thankfully, not so often these days, but back when harddiscs were new and RISC OS was version 3.10 and most apps came with varying versions of CLib, FPEm, and ColourTrans, it was a huge problem. Which is how the whole !Boot thing came to be.

It probably isn’t a good to have potentially crashy apps writing to Boot when it could instead be just destroying an unimportant subdirectory when it goes wrong.

You know, in all my decades of using RISC OS on real silicon and emulation, I’ve never come across anything that did this. Perhaps trashing it’s own settings, yes. Trashing everybody else’s? No.

and I think it is handier to have settings local rather than looking in Boot.

So there are three machines. App is installed on one. Two others are using the app (via ShareFS) at the same time. How do you handle both copies of the app writing the settings in the same place?

Like I said, the Choices thing exists for a reason. That it doesn’t seem useful to you doesn’t mean it isn’t useful to others.

Like I said, the Choices thing exists for a reason. That it doesn’t seem useful to you doesn’t mean it isn’t useful to others.

So useful the concept was extended in Select so different users of the same machine could use applications with their own preferred settings.

The fact that RO5 doesn’t, currently, have user specific logons is simply a deficiency in RO5 and most definitely not a reason to ignore Choices.

A bit off topic, but is there any documentation or tutorials you could recommend for how to use choices in c?

A bit off topic, but is there any documentation or tutorials you could recommend for how to use choices in c?

Not sure about documentation or tutorial, but all my apps use the config library from SFLib (which is based on OSLib). This is set up using config_initialise so that it knows the name of the application’s Choices sub-folder and the location of the application directory.

You can then use config_find_load_file to find a full filename to load from, and config_find_save_file to find a full filename to save to.

Both take a buffer to write the name into, and the leafname of the target file. The load will try all the options on Choices: and then try within the application folder; the save will supply a path on Choices$Write if that’s set, or a place in the application folder if it isn’t.

The code is all EUPL v1.2, so that’s good to borrow for use with a range of licences including GPL v2 and v3.

ETA: The config library is one of the oldest and nastiest bits of SFLib… I’m fairly sure it’s functional, but bug reports are welcome!

As any Directory. The path is <Choices$Write> for writing, and <Choices$Path> for read, assuming using RISC OS paths, do not know for UnixLib stuff.

Not quite, because you have to fall back to using the application folder if you can’t load from Choices: or if Choices$Write doesn’t exist.

@Steve

Not sure about documentation or tutorial…

Thanks, I’ll have a look at that! I’m following your tutorial, but I decided not to use SFLib in the end, since I couldn’t get it to link properly, or build it from source (I’m using GCC, not DDE for this project). By the way, and even more off topic, while your overview of flags to wimp_create_window is very comprehensive, I haven’t found a description of wimp_WINDOW_BOUNDED_ONCE, and a web search only gives hits for your tutorial… ;)

The only actual benefit accruing is the ease of transferring the application (including choices) to another computer.

When you remove the application, you also have to find the outside resources to remove. Once things are spread over the computer, then the need for package managers arrive.
Many are quick to re-inforce the rules but nobody has ever said I need the extra functioning of choices when I blah blah,
As long as they not imaginary people/cases that we are entertainng.
I dont find any difficulty working with choices apart from the location, and that could be changed to taste by editting !Boot.
I think the difficulty in an app managing it’s own choices, and probably the cause of the bloated !Boot app could be due to the poor set of commands available in an Obey file.
I can recall that the answer to this was to use BASIC, so why not have the !Boot and !Run files as BASIC in the first place?
My fix is to make C utilities to enhance the Obey system. (Read a line from a file, input from keyboard etc.)

so why not have the !Boot and !Run files as BASIC in the first place?

Obey can call out to BASIC, and then carry on afterwards. I’m not sure BASIC can do that.

you also have to find the outside resources to remove.

It could be worth having some sort of “Uninstall” mechanism where the thing will find these resources and remove them. Ditto anything cached in !Scrap.

Rick, quite right, I meant BASIC would have to have been integrated closer to the OS earlier on.
point 2: I recall some apps have had an uninstall app included.

so why not have the !Boot and !Run files as BASIC in the first place?

I would not like to see !Boot anything other than an Obey, in fact I would like to see it being a special limited Obey which can only set variables and load sprites. Something which is automatically run any time the filer sees it, is a security risk.

I dont find any difficulty working with choices apart from the location, and that could be changed to taste by editting !Boot.

The architecture of the Boot sequence needing change has been discussed before but it’s a big task though and no one has yet stepped up to have a go. Possibly because on first reveal to the community at least one person will dislike it and be load about it – no matter how good an idea it is.

I think the difficulty in an app managing it’s own choices, and probably the cause of the bloated !Boot app could be due to the poor set of commands available in an Obey file.

I have my suspicions that the available commands issue is something Julie has in mind with the CObey project, not just convert to C but extend the capabilities. I could be wrong.

I dont find any difficulty working with choices apart from the location, and that could be changed to taste by editting !Boot.

Which is precisely one doesn’t follow your earlier advice of finding Choices via the Boot$Dir variable…

I think the difficulty in an app managing it’s own choices, and probably the cause of the bloated !Boot app could be due to the poor set of commands available in an Obey file.

Not really. The reasons for separating out choices from applications has been explained in this very thread by several people now. Multi-user (ie. RISC OS 4.2+ and Six), read-only application storage (anything from RISC OS 3 onwards), easy upgrades…

I’m following your tutorial, but I decided not to use SFLib in the end,

I pointed to the code as an example of one way of doing what needs to be done, not as a recommendation to use SFLib. As I said, the licence is reasonably open if you wish to pinch bits of code.

since I couldn’t get it to link properly, or build it from source (I’m using GCC, not DDE for this project).

It’s normally built with GCC, so that’s… surprising. The version that is built with Norcroft is actually laid out on disc as part of the GCC build process, and then manually run through the DDE.

For what it’s worth, I don’t use the ALF version at all beyond work on the tutorial.

By the way, and even more off topic, while your overview of flags to wimp_create_window is very comprehensive, I haven’t found a description of wimp_WINDOW_BOUNDED_ONCE, and a web search only gives hits for your tutorial… ;)

It’s an instruction to force the window on screen once on the next call to Wimp_OpenWindow, AIUI. The main purpose is to ensure that windows don’t open partially off screen in small screen modes.

I probably ought to cover it in the tutorial at some point… :)