Is it possible (and reasonable) to add something like OnBeforeBackupCreated / OnBeforeBackupRestored / OnAfterBackupRestored?
The first one fires just before backupping, with the argument that contains the modifiable copy of the entire Preferences. Script, for example, could reset favorites / tab groups / layouts to machine-agnostic data.
The second one fires, as you guessed, right before restoring the backup. Here script could set favorites / tab groups / layouts, that are yet to be applied, to machine-specific values (reading them from external file, for example) etc.
The third should be executed ideally twice: immediately after the backup has been restored and then again after restart (the argument should contain a boolean to differentiate). Script could do some cleanup tasks here if needed, idk.
I'm not sure what you mean by "modifiable copy of the entire Preferences". If you mean the entirity of Preferences represented as a scripting object, then no - that would be a massive amount of work and not reasonable
But the config backup works by copying the files to a temporary folder and then zipping it - so we could pass the pathname of the temporary folder to the event, and the script could modify the raw files if it wanted to. If that's what you meant then yes, that's probably something we could add.
@Jon at least in my use case, something that might be helpful here as well, would be a way to force DOpus write the in-memory configuration to disk, that way you could then copy the desired files from the DO config folders, zip it and create a custom backup file.
Doing a config backup will do that, so you could delete the backup itself afterwards. (Or use it as the basis for your final zip. The .ocb backup is more or less just a zip file with the config folders inside it and some minor extras.)
I could see pre/post-backup events being useful as a way to replace/modify certain config files based on the machine name or similar (e.g. people often want separate Aliases lists on each machine, while the rest of the config stays the same; that just involves replacing one file). That wouldn't require scripting access to every config setting.
OnConfigBackup could be executed additionally after the backup is complete to operate on the final zip (you could provide similar to OnConfigRestore's step field).
ConfigRestoreData could contain the full path of the backup file.
Both ConfigBackupData and ConfigRestoreData could contain what mask with these flags (or even more granular if internally it is like that):
Both ConfigBackupData and ConfigRestoreData could contain encrypted field: in backup operation, tells whether the backup will be encrypted afterwards. in restore, tells whether it was initially encrypted.
Both ConfigBackupData and ConfigRestoreData could contain description field: null or the value of "Description" field associated with the backup.
Also there is a simple mistake in ConfigBackupData's description. I think the text should be: " ...the method receives a ConfigBackupData object when the configuration is being backed up."
