sight::module::io::session::SWriter were implemented. They read/write a root data object from/to a session file on a filesystem.
The session file is indeed a standard "ZIP" archive, while the compression algorithm for files inside the session archive is ZSTD. A standard archive reader could open a session file, if it is able to handle ZIP archive with ZSTD compression.
The archive can be password protected using AES256 algorithm and the compression level is set individually, depending of the type of data to serialize.
The service configuration includes specifying the file extension and the password policy for encryption.
<service type="sight::module::io::session::SReader"> <inout key="data" uid="..." /> <dialog extension=".sample" description="Sample Sight session file" policy=always/> <password policy="once" encryption="salted"/> </service>
The dialog policy specifies when the open dialog is shown:
- never: never show the open dialog
- once: show only once, store the location as long as the service is started
- always: always show the location dialog
- default: default behavior, which is "always"
The password policy defines if we should protect the session file using a password and when to ask for it:
- never: a password will never be asked and the session file will never be encrypted.
- once: a password will be asked only once and stored in the memory for subsequent uses. The session file will be encrypted.
- always: a password will always be asked. The session file will be encrypted.
- default: uses the builtin default behavior which is "never".
The encryption policy defines if we uses the password as is or with salt. It can also be used to encrypt without password:
- password: Use the given password for encryption.
- salted: Use the given password with salt for encryption.
- forced: Force encryption with a pseudo random hidden password (if no password are provided).
- default: uses the builtin default behavior which is "password".
ExActivitieshas been modified to use the new session services instead of atoms
core::tools::Systemthat use ROII to delete the associated file as soon as the
TemporaryFileclass is destroyed.
core::tools::System::RobustRename()now have an optional parameter to force renaming, even if the target already exists (it will be first deleted)
CrossCursorclasses that use ROII to restore back "default" cursor, even if an exception occurs
ui::xxx::dialog::InputDialogimprovement: add a "bullet" mode for password field.
ui::xxx::dialog::MessageDialogimprovement: add a "retry" button.
Closes #752 (closed)
How to test it?
ExActivities. Save and restore a session. (BTW, the layout is strange after the restore, but this "feature" was also present with atoms)