@dvratil: actually, there is an issue with saving on exit. Inside KJotsEdit::savePage we actually ask ETM to do the saving, which starts an async job.
However, if we do it when quitting, we tend to quit *before* the job dispatches, and lose unsaved changes :(

Is there a way to overcome this using ETM? Or should I just start ItemModifyJob by hand using non-async interface job->exec() here?
(actually, some feedback would probably be nice even when user presses Ctrl+S. E.g. change the cursor to "busy" one, or notify if there was an error and suggest to save it as a local file somewhere, etc...)

Hmmm, one option could be to add QEventLoopLocker into ETM to keep QApplication alive until the job in ETM has finished?

In D29291#660208, @dvratil wrote:

Hmmm, one option could be to add QEventLoopLocker into ETM to keep QApplication alive until the job in ETM has finished?

I've just tried it with the following patch:

There is an issue: ETM is created with KJotsWidget as a parent, so when we call quit(), we destroy everything, including the model.
It eventually forces us to release the lock, even before we catch the result() signal from the job.

However, KJots does save last changes with this patch, which is weird.
Probably that buys us just enough time so the job at least fires and reaches the server...

The ETM patch looks OK, but if the ETM is owned by the destroyed widget, then it likely won't work 100%.

Thinking of ETM, I see more issues with it: like no way to report an error back to the user when the ItemModifyJob fails. I created T13078 to solve this issue.

For now, I guess you should just use ItemModifyJob with exec() for now to workaround this.

In D29291#661833, @dvratil wrote:

For now, I guess you should just use ItemModifyJob with exec() for now to workaround this.

OK, thanks. I think I'll do it in a separate patch then, while let this one focus on using standard actions wherever possible.