Ask save location with dialog #1308
Conversation
82d3718 to
a2c3a6d
Compare
danirabbit
left a comment
There was a problem hiding this comment.
Left a few comments. This seems to work well, nice job!
| /* Copyright 2023 elementary, Inc. <https://elementary.io> | ||
| * SPDX-License-Identifier: GPL-3.0-or-later | ||
| */ | ||
| public class Scratch.Dialogs.AskSaveLocationDialog : Granite.MessageDialog { |
There was a problem hiding this comment.
As far as I can tell this is only used once. It seems kind of excessive to create a class for a MessageDialog since this is already quite abstract
There was a problem hiding this comment.
I don't want to clutter up Document.vala any more than necessary as it already well over 1000 lines. Also there will potentially be a need for another similar dialog to deal with external changes.
There was a problem hiding this comment.
That makes sense, but ask_save_location () is already an abstraction for this dialog so to add another layer of abstraction here seems like we're creating lasagna and we should have one or the other
There was a problem hiding this comment.
OK, will merge these one way or another.
Change button text to "Save Duplicate" Co-authored-by: Danielle Foré <[email protected]>
Use emblem-readonly-symbolic for locked document Co-authored-by: Danielle Foré <[email protected]>
Better primary text Co-authored-by: Danielle Foré <[email protected]>
|
@danirabbit Thanks for the review comments! I have actioned most of them. There are couple that require further discussion. |
| /* Copyright 2023 elementary, Inc. <https://elementary.io> | ||
| * SPDX-License-Identifier: GPL-3.0-or-later | ||
| */ | ||
| public class Scratch.Dialogs.AskSaveLocationDialog : Granite.MessageDialog { |
There was a problem hiding this comment.
That makes sense, but ask_save_location () is already an abstraction for this dialog so to add another layer of abstraction here seems like we're creating lasagna and we should have one or the other
|
I have now inlined the new dialog and made the other requested changes. Also fixed some new critical warnings on startup. |
danirabbit
left a comment
There was a problem hiding this comment.
Looks good and works as far as I can tell!
| if (!locked && !can_write () && source_view.buffer.get_modified ()) { | ||
| // The file has become unwritable while changes are pending | ||
| locked = true; | ||
| var details = _("File “%s” was does not have write permission."); |
There was a problem hiding this comment.
Bit late to the party but this sentence should probably be rephrased
There was a problem hiding this comment.
Oops! Thanks for noticing.
Speculative PR investigating possibility of replacing the infobar (with limited layout possibilities) with a dialog when it comes to dealing with problems saving to the current location.
Because of the focus changes caused by the dialog (which trigger handlers in document) several other significant changes were needed, principally giving the document a "locked" state in which it cannot be saved or autosaved and does not react to focus changes nor is saved when closed. The document enters this state (shown as a lock in the tab) whenever it cannot be saved to the current location and before the dialog is shown. The document remains in that state until "save as" is performed.
The ask save location dialog is called from fewer places than previously - now only after a save failure and after a status change to "not exist" or "unwritable".
External edits to the document still show an infobar - that can be revisited in another PR.
As now, the document is always opened unlocked and and does not become locked until edited (or unmounted or deleted). This allows viewing read-only documents without unnecessary interruption.
It needs to be decided if the more intrusive dialog is a better option. It can then be smartened up.