...that had been added with 33fa50e119 "Drop some
pointless assertions" back in 2011, but is no longer meaningful now that this is
a proper assert since 6e35794cad "terminate
XDesktop properly in unit tests"
Change-Id: Id8592df03f2a4c070af3cc691a0aa65ba8c2c061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160675
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
into the two entire separate cases they want to handle, there is
no reason to mix the two different cases like this.
Change-Id: I38e99e7ad6168a84e7a744f61407887825158902
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160248
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
For a DOCX file, there were four of them during a recovery
if the file was on a USB or renamed or whatever.
Now there aren't any.
Change-Id: I5cbad6e4ed1a1bc1d3b8e805a6b493f4ee61ec68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155567
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... with timed save" in order to restore useful comments
This reverts 24.2 commit 75d7464e7eb94df1ad9904ad750b27d99d91abc5,
where the ResettableMutexGuard's safety is cancelled by a g.clear()
// } /* SAFE */
and re-instated with a g.reset()
// /* SAFE */ {
Thanks Mike for explaining the obvious to me.
Change-Id: I98016a50221b734a38d14bce0a958c6af9e57944
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155514
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Only the "active" document was waiting for a user idle.
But that doesn't make sense because the background apps
still lock the foreground app during file save.
So all timed backups should wait for a user idle period
before starting their recovery / autosave.
Once an idle loop is triggered, no autosave will ever run again
until an idle timeout occurs! So a busy user who switches from
one doc to another without ever pausing still wouldn't ever
get a backup - even from the background docs!
Without this patch, only the first modified documents
(if backgrounded within 10 minutes) would ever
get a recovery save. So in pretty much every case
this patch makes sense AFAICS.
Change-Id: I6e9e04aa2e50895e53826b427cb52c129da43701
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155459
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
If we currently are in a user idle state, then don't delay
any recovery / autosave's until a future idle timeout.
Change-Id: Ie3953bb7456370d046b76a4cad816498dbfc85e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155462
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Unmodified documents were losing the enties from RecoveryList
when implts_deregisterDocument was triggered,
which prevented the Session recovery from being able to reload them.
Change-Id: I991a9821105aca81ec596b28341ef4335b817439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155380
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
With a successful UserAutoBackup, the document is fully saved,
and the recoveryInfo entry is removed.
So just avoid the recovery that would just be deleted anyway.
Change-Id: I3cc9fe2730640df48f450f900f33afc2df7f020a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155273
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
When a document is successfully saved (manually),
it is removed from RecoveryList (implts_markDocumentAsSaved)
and all of the temporary recovery files are removed
from the user's backup folder.
If the document is automatically saved (UserAutoSave)
successfully, it doesn't need to remain in the RecoveryList either.
storeToRecoveryFile can benefit from knowing if it will be removed,
so determine whether to bRemoveIt just prior to that call.
Change-Id: I2cb30b426e600cfe34987a091acaf8826316ede5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155272
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
In all but one case, the storeToRecoveryFiles were deleted
when the entry was removed from the RecoveryList
(and likely it should have been removed in that case as well,
since the program could not open that file anyway).
So, move that function into the flushConfig function
to ensure that recovery files are not orphaned
in the backup folder.
If the URLs are not cleared, and the recovery tries to load
the non-existing file, then LO will assert (or maybe crash).
(For implts_markDocumentAsSaved,
it does the deletefiles/flushCOnfig outside of the SAFE area,
but updates m_lDocCache with *pIt = aInfo inside the SAFE area,
so those deletefiles/clears cannot be cleaned up.)
(implts_cleanUpWorkingEntry and implts_deregisterDocument
both remove the m_lDocCache entry competely, so it was not
necessary to clear the URLs in those two cases.)
Change-Id: I765f3a815f28082495a7f286a8b28b977e0cad75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155118
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
There is no need to recover documents that are not modified,
and certainly not if there is no storeToRecoveryFile.
This specifically is nice for read-only files, new files,
or e-mailed files that have just been opened for viewing.
registerDocument: A just opened file has nothing to recover,
so wait until it has storeToRecoveryFile'd.
- Emergency and Session pre-register all documents
via implts_persistAllActiveViewNames, so no problem here.
resetHandleStates: shouldn't add, just update the existing states
saveOneDoc: shouldn't add before storeToRecoveryFile, only after.
Change-Id: I4a935ee325af6469b25c5bf3d2860c4065d9130d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154490
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The cache that holds document status did:
-saveDocs: for each cached document status:
-creates a copy of the cached status
-call saveOneDoc: given the copy
[-updateModifiedState should get called, updating the cache itself]
-saveOneDoc: flushConfig writes copy to RecoveryList (as modified)
-cache is updated with the results from saveOneDoc (*pIt = aInfo)
Now, it is easily possible that saveOneDoc changed the status from
modified, to not modified, wouldn't you think (if UserAutoSave)?
But since the copy was never updated, it reported as modified still!
storeToRecoveryFile can benefit from knowing the real modified status,
so do the update just prior to that call.
Change-Id: Iee1ddd0bf7bee25d5ba3e7abb1ac6713295906af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154683
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Mike K suggested I just use the simpler, faster function in this case.
Change-Id: I0f7f6611f12f88cd1daa4104b58eb44365a44ae3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155271
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Saving overtop of the working document during a crash save
does not sound like a safe thing to do.
However, an ODF recovery export is attempted
which will preserve unsaved modifications,
so avoiding this save should not cause data loss.
Change-Id: Ie993042b4c99d5dfb816727d4bfae5bca694d72f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155166
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
to attempt to make it obvious in code what kind of coordinate
system we are dealing with.
The idea is that by doing this, the compile-time type checking
will flush out inconsistencies between different code.
I started with vcl::Window::OutputToAbsoluteScreenPixel
and worked outwards from there.
Change-Id: Ia967d7a0bb38886695f3a761b85c8b9340ddb1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154676
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The document has just been saved
(perhaps manually, perhaps automatically)
and so the recovery ODF files are being removed.
So remove from RecoveryList since there is nothing
recoverable at this point.
Sure the document is open, and perhaps
there is even a modification already,
but if there are no recovery files available,
then why display it to the user?
Change-Id: I309cd7df573c960f75c2240c8b5cf171fc1d95be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155059
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
This patch fixes the following issue when pressing F1 while hovering on a menu entry that has submenus:
1) Place the mouse over a menu entry that has submenus (f.i. in Draw go to Format - Table)
2) A submenu will appear, however leave the mouse over "Table"
3) Press F1... the help ID used will be "slot:0" because LO is trying to find the help ID of the selected entry in the submenu, but since none is selected, then the generic "slot:0" value is used.
To fix this problem, this patch assigns a Help ID for the submenu (not for its entries) so that when no entry is focused, then the submenu HID is used.
IMPORTANT: note that pressing F1 on menus only work with gen and win. Due to bug 156376 pressing F1 on menus does not work with kf5 and gtk3 (yet).
Change-Id: I717e7669faac47a12c929129c0de98dee7f44439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154862
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Now that I know there is a config listener running in AutoRecovery,
listen for the config change and apply it immediately
instead of requesting the user to do a restart.
Change-Id: I69912c0e95c04cc1a5e680d5e8c59b15e94efb05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154664
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Maybe this would make a better UX, as the request suggests ... or maybe not.
css::document::XDocumentRecovery2 is introduced for this, allowing to query
the document dirty state duration.
Change-Id: I25997788bc5da261f7e4131616ab8d4a245de380
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154505
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
... instead of respective values from /org.openoffice.Office.Common/Save/Document
The history of the problem:
d0f9685d2c (2004-11-26)
made SvtSaveOptions use org.openoffice.Office.Recovery/AutoSave,
*in addition* to org.openoffice.Office.Common/Save/Document/*,
as "forward AutoSave/AutoSaveTime to new config location" part
of i#27726; at this point, org.openoffice.Office.Recovery/AutoSave/*
took precedence (they were read last).
8e6031e126 (2004-11-26)
implemented autorecovery.cxx, already reading
org.openoffice.Office.Recovery/AutoSave/*
d5b9283985 (2021-07-25)
made SvxSaveTabPage and SfxApplication::SetOptions_Impl use
officecfg::Office::Common::Save::Document::* instead of
SvtSaveOptions.
134f40136a (2021-07-25)
dropped SvtSaveOptions_Impl::ImplCommit, and its saving of
officecfg::Office::Recovery::AutoSave::* (which likely
detached officecfg::Office::Recovery::AutoSave from
officecfg::Office::Common::Save::Document, making UI edits
not stored to the former).
aeb8a0076c (2022-05-23)
made AutoRecovery::implts_readAutoSaveConfig read
officecfg::Office::Common::Save::Document::* instead of
proper officecfg::Office::Recovery::AutoSave::*.
This change restores the intended use, and deprecates corresponding
values in /org.openoffice.Office.Common/Save/Document.
Change-Id: I33d48e3945326c80d356bfc930ed8a7f042c982b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154500
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Another option would be to listen for config changes I guess.
However, this alternative method of setting the timer interval
(which I assume is related to Impress slideshows, but couldn't reproduce)
is basically never used.
At worst (in case this alternative method sets a non-zero time)
it will be the same as before where a restart is needed to
gain the new time.
I'm not worried about having the user wait for the current
timer to run out (in 10 minutes based on the default state)
before their new time kicks in.
Change-Id: Iaa2b9e3e0912918ae29aaf262b5d7f51924b8147
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154365
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Stephan Bergmann