I’m currently in Málaga for the GStreamer hackfest. Hopefully, many bugs will perish. In the meantime, here’s a quick status update of stuff I’ve been doing in recent times in Pitivi.
- Cleanup the code for gtk actions so that the code is more readable and robust, fixing 629208 in the process.
- Cleanup the menus (again).
- Avoid having the viewer eating the CPU while idle.
- Fix various problems such as “Select unused clips” not working in treeview mode or reimplement removing all timeline instances of a clip when removing it from the media library.
- With the help of Brian Grohe, merge and delete spam user accounts on the wiki. I only have to fix image uploads and the https certificate issue now.
- Start fixing 629855; see below for details.
It turns out that pitivi was secretly writing autosave/backups of your project files (and deleted them when successfully saving/closing), but it did not actually use them. You’d have to know they exist, when they exist and where to find them, which is hardly intuitive.
So, I set out to fix this. Along the way, I ended up making the “unsaved changes” dialog more helpful. This is the result:
Then I worked on the actual dialog to prompt the user about the existence of an autosaved project file. It uses uses the same mind-blowing human-readable time formatting nekohayan technology, as you can see in the various following scenarios:
If you ignore the backup file, it will obviously be deleted when you cleanly save/close the project.
The big question is however, what we should do if the user selects to restore from backup:
- Should we simply rename the backup file to overwrite the “old” project file and then load it? This would mean the “old” project would be lost. In theory nothing should go wrong with that…
- If we want to be paranoid perhaps we could load the backup file as a temporary file and force the user to use “Save as” instead of a regular Save, but I’m not sure if that’s what users need. Thoughts welcome on this one, but I’d really like to have a simple solution.