After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734068 - gedit should quit after saving through "Save before closing?" dialog
gedit should quit after saving through "Save before closing?" dialog
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 736488 741498 748093 774071 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-07-31 17:49 UTC by Martin Simon
Modified: 2016-11-10 15:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Saving a content of file before closing gives us the double check that file name is correct or not. (879 bytes, patch)
2014-09-02 12:44 UTC, Ankita Patil
none Details | Review
gedit-document: fix close after save functionality (2.97 KB, patch)
2016-04-15 17:21 UTC, Ray Strode [halfline]
accepted-commit_now Details | Review

Description Martin Simon 2014-07-31 17:49:09 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
Comment 1 Sébastien Wilmet 2014-09-02 12:04:22 UTC
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
Comment 2 Ankita Patil 2014-09-02 12:44:17 UTC
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. :-)
Comment 3 Sébastien Wilmet 2014-09-11 15:42:39 UTC
*** Bug 736488 has been marked as a duplicate of this bug. ***
Comment 4 Sébastien Wilmet 2014-12-14 11:06:44 UTC
*** Bug 741498 has been marked as a duplicate of this bug. ***
Comment 5 Sébastien Wilmet 2014-12-14 12:12:34 UTC
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.
Comment 6 Sébastien Wilmet 2015-04-18 09:45:48 UTC
*** Bug 748093 has been marked as a duplicate of this bug. ***
Comment 7 Jan Niklas Hasse (Account disabled) 2016-02-24 23:01:16 UTC
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.
Comment 8 Ray Strode [halfline] 2016-04-15 17:21:20 UTC
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.
Comment 9 Ray Strode [halfline] 2016-04-15 17:22:06 UTC
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
Comment 10 Paolo Borelli 2016-04-16 23:59:52 UTC
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.
Comment 11 Ray Strode [halfline] 2016-04-18 17:47:10 UTC
Hmm actually looks like this is already fixed in 3.20 thanks to GtkSourceFileSaver and commit abcf3bfdb etc
Comment 12 André Klapper 2016-11-10 15:54:38 UTC
*** Bug 774071 has been marked as a duplicate of this bug. ***