Skip to content

Improve Python API - Document Autosave

Grum 999 requested to merge grum/krita:grum999/python_api_document_autosave into master

Following discussion from MR #2147

  1. Explicit autosaving switch

Expose to Python API the possibility to deactivate/activate for a document, the autosave, using an implementation that is not based on setInfiniteAutoSaveInterval()

note When activated, it will use default Krita autosave settings

It means that even when autosave is set to True, under condition Krita will not proceed to automatic save of document:

  • autosave is globally deactivated
  • document is read-only

Test Plan

  1. Set Krita autosave delay to 1 minute
  2. Create a document, save it
  3. modify document (do not save)
  4. wait a minute
  5. check in document directory the "autosave" version is here (+timestamp)
  6. modify document
  7. in scripter, execute following script
from krita import Document
from PyQt5.Qt import *

import tempfile
import os.path


def sleep(value):
   """Do a sleep of `value` milliseconds"""
   loop = QEventLoop()
   QTimer.singleShot(value, loop.quit)
   loop.exec()


class TestDocument():
    def __init__(self):
        self.newDoc = Krita.instance().activeDocument()
        self.newDoc.setAutosave(False)
        print('autoSave (inactive)', self.newDoc.autosave(), False)
        sleep(1000 * 65)
        print('--I-1')
        sleep(1000 * 65)
        print('--I-2')
        sleep(1000 * 65)
        print('--I-3')
        self.newDoc.setAutosave(True)
        print('autoSave (active)', self.newDoc.autosave(), True)
        sleep(1000 * 65)
        print('--A-1')
        sleep(1000 * 65)
        print('--A-2')

TestDocument()
  1. until "---I-3" message printed, check autosave document timestamp (should not be updated)
  2. after "---A-1" message printed, check autosave document timestamp (should be updated)

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.

Merge request reports