SparkFS 1.52 Choices

SparkFS 1.52. Is the Close icon intentionally missing from the Choices window? A bit inconvenient/odd. Can’t step back without closing the app or hitting Save.

Hi Fred, on gitlab removing the close icon is written up as style guide compliance.

Intentional then. OK. Does it say why :-). Should there be a Cancel in window?

Over to those who know – the close icon is something you often see, but it does not feel right.

Page 50 of the Style guide refers, see “Persistent dialogue boxes”.

Close icons are a must not, on closing it would be unclear whether any actions would be implemented or lost, it says. There should be a Cancel action instead, it says.

The text is copyright and the PDF locked so it not quoted here.

Let the litigation commence.

But it is not one of those situations where cancel could reset things. If you click on a setting in choices it has immediate effect. There is no mechanism for Cancel to put things back how they were – reload the choices file if you like. Save writes to the choices file, and will have an effect the next time the program is run.

It is convenient to change the compression type to None, get rid of the choices window, mess about with archives, and be happy that next time choices will be re-loaded with the old settings.

I suppose then, that if one makes no changes the done thing is to select ‘Save’ anyway.

User choices, p91, in the Style Guide looks to better cover the situation. (Still no close window icon though!)

A Set button makes changes for the current session without saving.

Thank you for the explanation of how this element of SparkFS work.

I haven’t seen the dialogue box myself, but do I have this right?

• Any setting changes take effect immediately
• The Save button makes those settings default for next launch
• Changing a setting then quitting SparkFS without clicking Save results in the setting returning to its old value next time SparkFS is started.

It almost sounds like there should be separate “OK” and “Save” buttons, although then we’re back in the land of confusion. I wonder what the best option is here…

Edit: As pointed out, page 91. The example dialogue there has both Set and Save buttons.

But it is not one of those situations where cancel could reset things. If you click on a setting in choices it has immediate effect.

Ah… that’s where you’re going wrong, then. Page 51 of the Style Guide says “Both types of dialogue box¹ should be characterised by delayed action: the user has to make choices and then click on OK … before the choices take effect. This contrasts with the instant effect of, for instance, dragging a scroll bar. Toolboxes … have an instant effect.” (my emphasis).

So you then have a Set button to apply the choices (using Adjust to keep the dialogue open for more fiddling), optionally Save to make the values the new default for the future, and Cancel to forget the changes (or reset the dialogue contents if Adjust is used). But no close icon, as it isn’t clear to the user whether that will Set, Save or Cancel any changes which have been made.

¹ Persistent and Transient.

@Chris Mahoney you have summarised the situation correctly.
@Steve Fryatt – I never said it was a dialogue box. It is kin to the RISC OS task manager with memory sliders that have instant effect. Change the name from ‘Choices’ to ‘Manager’…
Thanks for the impressive knowledge of the style guide (and @David Pitt).

I never said it was a dialogue box.

Having gone to check, it looks and quacks like one, though: it’s accessed via a menu entry with an ellipsis (which the Style Guide tells us leads to a persistent dialogue box), and has an action button labelled “Save” in the place that you’d expect to find one in a dialogue box.

Given that other bits of the OS generally use the delayed-action approach, I’m assuming that’s the way that ROOL are trying to move SparkFS. Presumably whoever made this change hadn’t noticed that the dialogue didn’t actually work as expected, however.

It would be nice if that work was completed¹, but the expedient option for now might be to restore the close icon and change the “Save” button to read something like “Update Defaults” or “Make Default” so that it can’t so easily be confused with a button that applies pending changes.

¹ Assuming the work is done correctly, the only change to the user experience is the need to Adjust-click on a Set icon to make the changes apply and leave the dialogue open. It’s one more click, but makes things consistent across the OS.

@Steve Fryatt – sounds right to me.
I struggled to design the Choices window. It got grudging acceptance at the time. Not long after I started providing module specific *commands and putting them in obey files in the SparkFS.Autorun folder.

If I do another weeks work, I’ll do Zip encryption.

If I do another weeks work, I’ll do Zip encryption

That would be really brilliant!
Currently I believe SparkFS can only encrypt/decrypt Spark files & directories … and with only an 8-character password – extra characters are just ignored and is rather dangerous. I would hope that any Zip encryption is not so limited.

Spark files/dirs support Garble (32 character password) and DES (8 character password (limitation of the algorithm), extra characters ignored). Garble is trivial to break. DES has fallen out of favour.
There is a good Wikipedia article on Zip files which explains the history. The original encryption method was “Zipcrypto” – however that is known to be very weak (there’s a program to break it ‘bkcrack’). Later zip methods AES-256 are stronger but less well supported.
I would be doing Zipcrypto – at least you then have some encryption for zips.

One could argue that weak encryption is worse than no encryption.
https://web.archive.org/web/20171028074139if_/https://www.cs.auckland.ac.nz/~mike/zipattacks.pdf

As you mention:
https://github.com/kimci86/bkcrack
(breaking time can be measured in minutes, not days)

I wouldn’t be surprised if there weren’t several gov computers keeping the Tea warm trying to break code :-)

@David P: I know there was a printed manual for SparkFS, as I am looking at mine, for v1.22 dated 24 Feb 1993! I know it is out of date, but it would be good if the Ovation source could be found and made available to ROOL if not already – perhaps then it would be possible to update it?

There’s a PDF on his website. It’s not long, about 30 pages.

One could argue that weak encryption is worse than no encryption.

This.

I’d rather have no encryption than something that isn’t worth the name. That could just give a false sense of security.

But then again it is nice to be able to open zips that have been encrypted…

The Ovation Pro version of the SparkFS manual is here:

https://www.davidpilling.com/software/sfsman.zip

I stopped updating it in 1993, there is much useful material in the ReadMe. Nice project for someone to write a new manual, although not much incentive, if there are going to be user interface changes.

Encryption… I read the paper Rick referenced above, interesting. It is a big debate.

My POV is making small achievable steps. Once you have any encryption for zips it is easier to add other methods.

What’s the end user of RISC OS these days – military, organised crime, people who cheat on their partners…

With respect to the behaviour, look, etc, of the Choices window in SparkFS, the Choices/Settings windows in SyncDiscs and Snapper behave in a somewhat similar manner. DPlngScan also has some differences to the Style Guide in it’s various settings dboxes. Maybe I should take a look at these apps with a view to checking on style guide compliancy, and modifying where possible.

I’d rather have no encryption than something that isn’t worth the name. That could just give a false sense of security.

I disagree, you aren’t always trying to protect against nation state level interception.

You wouldn’t put confidential information on a postcard, you would use an envelope, even though its easily cracked it prevents casual interception. The same with email, for many years some RISC OS dealers required you to email credit card details for payment, if you used plain text it could be easily scanned and intercepted by any compromised email gateway. Putting the details in a weakly encrypted zip (or even something obscure like a drawfile) raises the bar too high for not all, but the vast majority of threat actors.

Putting the details in a weakly encrypted zip (or even something obscure like a drawfile) raises the bar too high for not all, but the vast majority of threat actors.

Probably true.
When you stop to consider, the average thief is stealing because it’s easier for them than working for a living.
The more difficult you make things when they (try to) look at your stuff, then the more likely they are to head for the easy pickings.