[android] Make recorder docker not trap files
On Android, no user-visible directories are writeable by default. That means QDir::homePath() is an application-internal directory by default, which means the recorder docker's default storage location dumps file in a place inaccessible to the user. To add insult to injury, the user can't actually create a timelapse video from these files on Android due to an absent ffmpeg, meaning all they do is take up space. And to add torture to insult, if the user changes the recording directory to an external one while they have files lingering in the internal directory, they can no longer revert to that directory, rendering them unable to delete those (often large) useless files without clearing Krita's data altogether, losing all configuration.
This patch changes the recorder's default directory to be empty on Android, since we don't have a sensible default we can use. The user must choose a directory themselves, where they will give Krita permission to write to that directory.
That requires the docker to actually handle an empty directory properly. It no longer tries to start an auto-recording when the path is empty. When the user hits the record button without selecting a directory, they will be prompted to do so before recording starts (or aborts, if they don't pick any directory.)
Finally, to rectify the past situation, if the default path is selected, it will get turned into an empty path instead. If the internal directory exists and the user has selected a different directory for us to write to, the files will be moved over.
Test Plan
- Open Krita on Android, observe that the default directory is empty. Hit Record, observe that it lets you pick a directory.
- Check the auto-record checkbox while the directory is empty. Observe that it doesn't cause errors.
- Record stuff to the default internal directory with an older version of Krita. Install this version, observe that the path gets cleared. Pick a directory, observe that the files from the internal directory get moved to it.
Formalities Checklist
-
I confirmed this builds. -
I confirmed Krita ran and the relevant functions work. -
I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!) -
I made sure my commits build individually and have good descriptions as per KDE guidelines. -
I made sure my code conforms to the standards set in the HACKING file. -
I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy. -
Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?
Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.