Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay asking for save location if cannot determine write access #1280

Merged
merged 11 commits into from
Mar 18, 2023

Conversation

jeremypw
Copy link
Collaborator

@jeremypw jeremypw commented Mar 4, 2023

Fixes #1272
Fixes #1256
Fixes #1183

  • Documents on a filesystem that does not have FileAttribute.ACCESS_CAN_WRITE attributes now default to writable on loading so that the infobar does not show. The infobar only shows if creating a backup file for the document fails after actually changing the document.
  • Several methods had to be made async as a result of this change so that failed save/save as always triggers an infobar and cancels operations such as closing a window or tab.

As in master, if the FileAttribute.ACCESS_CAN_WRITE attribute can be determined and is false then the infobar shows immediately on loading. It is an open question whether this is desirable or whether the behaviour should be the same for all documents. An unwritable document could be opened only for reading and showing the infobar is a little irritating in that case. Also, a writable document could theoretically became unwritable while it is open and this should be handled. It should be relatively easy to handle that in a separate PR if this PR is accepted.

Tests:

  • Open a document on a remote non-native (e.g. WebDAV) system which is unwritable .
  • Open the parent folder as a project
  • Turn off autosave
  • Make some changes
  • Attempt to close the document by closing the tab, closing the window, closing the project etc.
  • Attempt to force save the document with <Ctrl>S or the save button
  • Attempt to save the file under a different name on the same folder with <Ctrl><Shift>S or the Save As button.

In each case the document should remain open and a suitable infobar appears if not already present.
Cancelling the operation should do that and keep the document
Close without saving should allow the operation to proceed and the changes are lost.

Note : Duplicate the tab - works as normal - the duplicate is created as a writable New Document on the local file system.

Repeat the above tests on a local file in a writable folder. No change from master
Repeat the above tests on a local file in an unwritable folder. No change from master

Repeat the remote unwritable tests only with autosave on. On opening no infobar appears until a change is made to the file or a save is forced. Unedited doc can be closed without issue.

With autosave on try to edit and close the document in quick succession in everycase the changes should have been saved when the doc is reopened

@jeremypw
Copy link
Collaborator Author

jeremypw commented Mar 5, 2023

Closing as #1280 overlaps this one and is simpler.

@jeremypw jeremypw closed this Mar 5, 2023
@jeremypw
Copy link
Collaborator Author

jeremypw commented Mar 5, 2023

Closed wrong PR!

@jeremypw jeremypw requested a review from a team March 5, 2023 18:35
Copy link
Contributor

@zeebok zeebok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code look good! I haven't tested yet but if you feel confident feel free to merge, otherwise I will try to test this as best I can tonight.

@zeebok
Copy link
Contributor

zeebok commented Mar 17, 2023

Yep what I could test does seem to work!

@jeremypw jeremypw merged commit 598bbe9 into master Mar 18, 2023
@jeremypw jeremypw deleted the try-save branch March 18, 2023 09:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants