will scripting work on different configs?

[admin]

If I'd send you a photo of myself in my current dress and makeup you'd never touch XY ever again...

So...you're wearing a dress and makeup now?
Does that also imply a wig, bra and high heels for the full cross-dressing effect?

Sure I'm cross-dressing (wig implied), but not crossing to one of the old-school genders...

[admin]

I'm currently playing with the following solution (inspired by lots of Cologne beer, and by some of the posts here). You have an option to enable a "script compatibility mode" (or so). If enabled then whenever a script is executed, a couple hard-coded settings (see list below) are ensured for the script (and reset -- if possible!* -- to the state before when the script is done). Hard-coded because this is the only way to ensure that script exchange between users works.

* There are situations when resetting them would destroy the final picture rendered by the script (think of script to "select 3 newest files", and then reset to list "single select"...hmmm) -- so what to do???

These are the settings (using jacky's list) that would be the background for every script -- they are identical with the factory defaults:
YES - View|List Style|Multiple Select
YES - Show floppy drives
NO - Show hidden drives
YES - Show hidden files and folders
YES - Show system files and folders
YES - Show My Network Places
YES - Show folders in list
YES - Sort folders apart
NO - Keep folders on top
YES - Natural numeric sort order (XP/Vista)
NO - Show folder sizes in file list
NO - Resort list immediately after rename
??? - Auto-refresh on file system changes

Auto-refresh is a problem. It can disturb scripts, but it also can help scripts... I tend to disable it: more control.

[jacky]

Hard-coded because this is the only way to ensure that script exchange between users works.

I tend to disagree here, with this statement and with the solution...

With the statement, because settings don't have to be hard-coded, it could rely on the script (and its author). I hear you say that if one don't think that he needs to make sure some option is enabled or disabled, because it's set that way on his own config, he'll then write an "incorrect" script, but that's just one of many ways one could write such a (bad) script.
Here's another one : if I assume that because I always sort by Name asc everyone else does too, so I forget to put a "::sortby name, a" on my script.

I also don't really like this solution, because it sounds like an option I'd have to enable so my scripts are using this "compatibility mode", but since that means a change of option, it is also likely to mean a refresh of List and Tree as well if/since my own options aren't the same. (eg. I don't show floppy drives)

So that could/would slow down my scripts, whenever I use them, even if there's only one for which this mode is actually required and one I use rarely. (Or I could not activate this mode, but would have to remember to enable it when needed...)

I know I keep going back there, but I feel like the ability for a script to change settings would be best because it allows the script to ensure what whatever settings should be set a specific way will be set as they should, and XY could remember which settings are changed & restore their previous values when the script execution ends.

What could be added to this would be, why not, such a "compatibility mode" that could be enabled by the user (who wants to feel safe), or by the script itself (since a single "use_compatibility" might be easier than a bunch of "set_settting <name>, <value>" - although the later ensures that only required settings are affected)

Plus, what if for one script someone whishes that an option could be set to another value than the factory default/compatibility mode value (like don't show any hidden/system items) ??

[admin]

Hard-coded because this is the only way to ensure that script exchange between users works.

I tend to disagree here, with this statement and with the solution...

Okay, I forgot to mention that a command "::setting name, value" would still be needed to overwrite the default settings if wanted.

Anyway, thanks for your thoughts. I think I have another beer...

[jacky]

Okay, I forgot to mention that a command "::setting name, value" would still be needed to overwrite the default settings if wanted.

Oh, right, well if you omit the best part of it, of course...

Okay, have another beer then!

[admin]

Okay, I went for the full control way. Added a number of setting commands. Let's see how far we get with them...

[j_c_hallgren]

..but rather a common way to set a number of options using one command instead of multiple commands.

Looking at the new Setting cmd, I was thinking it'd be better if instead of

Code: Select all

::setting shownethood, 1::setting sortnatural, r 

one could say

Code: Select all

::setting shownethood, y, sortnatural, r 

where the various "name, value" pairs would be repeated as needed, and instead of 0 and 1, you could also use F and T.
This would reduce the redundancy if a large nbr of cmds were needed, plus make it just a tad bit more user friendly.

[jacky]

Okay, I went for the full control way. Added a number of setting commands. Let's see how far we get with them...

Looks nice! However, I still thinking that it would be better if XY would restore settings on its own.

Sure, if a script is well done it will ensure required settings are what they need to be, and then restore their values.

But having XY to do it would ensure the user that his settings will not be altered by any script, and there are cases for which it may be useful. For instance, one may not realize that a script changed his settings, and forget or not realize than pressing Cancel during an input-command means those settings are now changed (and there's no way for the script('s author) to do anything about it).
Or just that after a step or syntax error, the script execution is halted before it reached the end. Hence why I said that XY should restore the settings changed by the script once its execution was done, regardless of how it actually ended (normal, error, cancel, etc)

[serendipity]

Okay, I went for the full control way. Added a number of setting commands. Let's see how far we get with them...

Looks nice! However, I still thinking that it would be better if XY would restore settings on its own.

Sure, if a script is well done it will ensure required settings are what they need to be, and then restore their values.

But having XY to do it would ensure the user that his settings will not be altered by any script, and there are cases for which it may be useful. For instance, one may not realize that a script changed his settings, and forget or not realize than pressing Cancel during an input-command means those settings are now changed (and there's no way for the script('s author) to do anything about it).
Or just that after a step or syntax error, the script execution is halted before it reached the end. Hence why I said that XY should restore the settings changed by the script once its execution was done, regardless of how it actually ended (normal, error, cancel, etc)

I totally agree with that. No matter what i do with scripts (execute, cancel midway, error etc), my settings should be reset back to original. Else, there is a good chance scripts will piss people off.

[TheQwerty]

Okay, I went for the full control way. Added a number of setting commands. Let's see how far we get with them...

Looks nice! However, I still thinking that it would be better if XY would restore settings on its own.

Sure, if a script is well done it will ensure required settings are what they need to be, and then restore their values.

But having XY to do it would ensure the user that his settings will not be altered by any script, and there are cases for which it may be useful. For instance, one may not realize that a script changed his settings, and forget or not realize than pressing Cancel during an input-command means those settings are now changed (and there's no way for the script('s author) to do anything about it).
Or just that after a step or syntax error, the script execution is halted before it reached the end. Hence why I said that XY should restore the settings changed by the script once its execution was done, regardless of how it actually ended (normal, error, cancel, etc)

I totally agree with that. No matter what i do with scripts (execute, cancel midway, error etc), my settings should be reset back to original. Else, there is a good chance scripts will piss people off.

I disagree when it comes to normal conditions. If XY automatically resets anything changed in a script then I can't write a script that just changes settings, and I as a script writer will become very frustrated with that.

Proposal: A new command ::RestoreAllSettings when it is called it *ahem* restores all settings that were changed in the script.

Anyone not wanting their settings changed can add it to the end of all scripts, or there could be an option to have XY automatically append it to every script.


Now if a script ends unexpectedly, I wouldn't have any objection to it automatically restoring settings.

[fishgod]

Anyone not wanting their settings changed can add it to the end of all scripts, or there could be an option to have XY automatically append it to every script.

Wenn a script ends unexpected, how should a commad at the END be parsed?

It would be better to add such a command to be beginning of the script, so that the scripting-engine knows if the setting made are valid through the runtime or should be make permanently.

[TheQwerty]

Anyone not wanting their settings changed can add it to the end of all scripts, or there could be an option to have XY automatically append it to every script.

Wenn a script ends unexpected, how should a commad at the END be parsed?

It would be better to add such a command to be beginning of the script, so that the scripting-engine knows if the setting made are valid through the runtime or should be make permanently.

Please read my post again. The first three-quarters pertain to when the script ends correctly. And then I suggested that if a script ends unexpectedly it should reset the settings regardless of that command being present or not.


I disagree with that command being at the beginning or just signifying that when the script ends it should restore the settings. By restoring the settings when called it becomes possible to continue a script after settings have been restored. In addition, it makes the script's intents clearer and doesn't add confusion when a user is trying to read and understand a script.

[fishgod]

Your right

Next time I will try to read twice before posting...

[admin]

Okay, I agree with everything (minus the confusion and the rubbish -- kidding). What about this: I add a variant command to "setting" called "setting_temp" or "settingT" or "settingR" (for restore). All settings set using this variant will be auto-reset when the script ends (or is cancelled at any point).

[fishgod]

I add a variant command to "setting" called "setting_temp" or "settingT" or "settingR" (for restore). All settings set using this variant will be auto-reset when the script ends (or is cancelled at any point).

that sounds good to me