zer0 wrote:And if a user accepts a particular default value passively, he/she may not form said expectation. Actually, I'd say that most users don't read changelogs -- they want to use the app instead...
I never said they should have to read the changelogs, nor did I even suggest that to be the case. In fact, by not changing the user's settings to match changes to the defaults they should have less need to check the log, as XY is respecting their settings instead of using its own.
Since you balked about the deletion prompt example, let me break this down for you using:
; Tweak: Separator between RegExpPattern and ReplaceWith, Default = " > "
RegExpRenameSep=" > "
There are three possibilities for how this value gets set:
1) If the user does not know it exists they have passively accepted the default value.
2) If the user knows about the tweak but feels " > " is a good value they have directly accepted the value.
3) If the user knows about the tweak and changes it they have rejected the default value.
If in the next version of XY Don wanted to change it to " >> " by default what are his options:
A) Change it for everyone regardless of existing values.
B) If the existing value is " > " change it to " >> ".
C) Only use " >> " for new installations.
Option A is an awful user experience for everyone, agreed?
Option B is what you are pushing for, but how does Don discover whether the existing value is because of 1 or 2 above? Then assuming it is 1 you still confuse users because they have grown accustomed to using that setting within XY. It doesn't matter if they didn't know they could change it, their expectations have been set by previous use.
Option C does not change what the user has to do and it doesn't overwrite/delete the user's settings. To the user this is just like nothing changed and they are unaware until they either read the change log or do a fresh install. If the user is doing a fresh install I think it is acceptable that they'll expect the new install to not function exactly like their previous one did until it is configured similarly.
Option A and B are very disruptive to the user's workflow; option C is not.
Option A and B do require that the user pay attention to the change log as they never know when XY is going to decide to change their settings; option C only requires it when the user discovers that their value is no longer the default.
Now sure there is the possibility that a user who has never before used Regex Rename will begin using it and for them " >> " might be a better option, than the " > " they passively accepted, but how is XY supposed to determine this? This would require XY to essentially add two bits to each and every setting, one to track if it's been set by the user, and another just to see if it's been used.
What a waste of effort that would be, in addition to creating a much more complicated code base, just to make things easier for a fraction of the minority of users for something that is rarely an issue at all.
zer0 wrote:Settings in GUI and INI are not the same, there are reasons for their segregation.
They are only segregated for the sake of simplicity. There is no need to present a new user with all those options, especially when some are needed by so few. However, there is no actual difference between a setting in the GUI and the INI. They are both settings and they both change how XY behaves. The user does not become accustomed to which checks and values are set, they develop habits and expectations by how XY behaves.
zer0 wrote:Once again, why are we assuming that a user has approved that setting? When it comes to default values, aren't those values supposed to represent a "best case" scenario for users?
No, they are not. Default values define the initial behavior of XY and the goal when determining how they should be set all comes down to selling XY. That's it - it's not about the best case, that's different for each user. It's what would be most appealing to a prospective customer to convince them to buy XY. Often these default values also correspond to better performance or ideal settings for the majority of users, but, again, the goal is to sell XY not achieve that be-all-end-all of subjective best case scenario.
zer0 wrote:Having changed the BackgroundedFileOps tweak value from "14" to "7", I am no longer experiencing this problem. So, if I am correct, scripting's move command is incompatible with XYcopy if applied to intra-volume moving jobs?
The move scripting command works perfectly with XYcopy as far as I can tell. There is no incompatibility because it respects a user's settings for what operations should be done in the background, and if the user wants the script to use a different behavior than the global setting they can use the setting command to do just that.
EDIT: Not that this wall of text needs to be bigger, but as we've determined that the problem was script writer error and is thus resolved I have no intentions of continuing this discussion.
XYplorer Beta Club
).
