GNOME Bugzilla – Bug 734068
gedit should quit after saving through "Save before closing?" dialog
Last modified: 2016-11-10 15:54:38 UTC
When trying to close gedit file which is not saved before, the "Save before closing?" dialog appears. I can choose "Save As..." and save the file correctly. But then gedit does not continue in requested action (quit) and return back in edit mode (the normal one). The gedit should respect requested action and quit as requested. App version: git master Reproducer: 1. Open gedit 2. Type some text 3. Try to close gedit 4. In "Save before closing?" dialog choose "Save As..." and save the file Actual result: The file is saved BUT the gedit is still running Expected result: The file is saved AND the gedit is not running anymore
Some discussion on IRC: <swilmet> when quitting with unsaved docs, the "save as" works, no? it is "just" that gedit doesn't quit after that <ankita> yes it works...but case can be relate to tabs too..not only when quiting the gedit app. <swilmet> ah ok <swilmet> ankita: for closing an unsaved tab, the current behavior has the advantage that the user can double check that the filename fits the contents <swilmet> ankita: and with several unsaved documents, when quitting gedit, the Save As dialog appear one by one, it's not convenient, there is just the "Unsave Document 1", "Unsaved Document 2" etc to distinguish between the different documents to save <swilmet> so I would change that altogether <swilmet> ankita: "Save changes to document “Unsaved Document 1” before closing?" <swilmet> can be replaced by: <swilmet> "Save changes to document “Unsaved Document 1”?" <swilmet> so the meaning of the buttons "Close without saving", "cancel" and "save as" better match the behavior of what will happen <ankita> swilmet yeah right..this will tend to no code changes at all i think ( by logic ) <swilmet> ankita: yes, I think it's nice to double check the filename with the contents <swilmet> for closing several unsaved documents at the same time, another behavior should be found
Created attachment 285132 [details] [review] Saving a content of file before closing gives us the double check that file name is correct or not. Refer swilmet comment. :-) Any suggestion on this is most welcome. :-)
*** Bug 736488 has been marked as a duplicate of this bug. ***
*** Bug 741498 has been marked as a duplicate of this bug. ***
When there is only one Unsaved Document to save, I think it's not really needed to double check that the content fits well the filename, so the gedit window can be closed directly. And there is anyway the "Cancel" button, so if the user has some difficulties to choose a good filename, he/she can click on "Cancel", come back to the Unsaved Document, scroll its content, and then save it manually. On the other hand, when there are several Unsaved Documents to save, in my opinion another dialog window would be better, see bug #741504 for that.
*** Bug 748093 has been marked as a duplicate of this bug. ***
Any news on this? As said in comment #5: The use can just click Cancel if he has any doubts about the file being saved.
Created attachment 326120 [details] [review] gedit-document: fix close after save functionality Right now if a document is modified when a user tries to close the buffer, we pop up a dialog asking if they would like to save before closing. If the user says yes, we proceed to save the document but then fail to close it. This is because we try to close the tab before marking the now saved document as unmodified. The close operation then fails. This commit changes the code to set the document unmodified, earlier, in time for the close tab operation to succeed.
This ^ is what we're going to ship in rhel 7 to address the issue. downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1247999
Review of attachment 326120 [details] [review]: The patch looks good to me. Thanks a lot for fixing this, it's been long overdue. Can you push this to all relevant branches? Some very minor nitpick below. ::: gedit/gedit-document.c @@ +1345,3 @@ g_object_ref (doc); + gtk_text_buffer_set_modified (GTK_TEXT_BUFFER (doc), FALSE); I'd move this before the ref(doc), since that line is specific to the async op.
Hmm actually looks like this is already fixed in 3.20 thanks to GtkSourceFileSaver and commit abcf3bfdb etc
*** Bug 774071 has been marked as a duplicate of this bug. ***