GNOME Bugzilla – Bug 527133
unable to close multiple files without saving
Last modified: 2010-11-07 03:33:35 UTC
Scenario: two books are opened and edited. Then attempt to quit. A dialogue window appears offering the options to: select all clear selection save selected don't quit There is no option to quit without saving any files.
We do not want you do lose work. If you really do not want to save, click "clear selection" so nothing is selected and then "save selected". We are open for suggestions for improvements of the GUI, but it is very important that it is not easy to lose work.
To instruct a user to "clear selection" and then "save selected" is contradictory english. Add a new button: "close without saving"
> Add a new button: "close without saving" That's precisely the GUI we want to avoid. One click and too much work is gone.
Make a proposal for an interface and we can consider it. Closing this for now.
If you want to insult the intelligence of the end-user that is your prerogative. Now the dialogue window contains poor instruction; to tell the user to clear selection and then save selected? Just imagine trying to write a tutorial to describe that task! Further suggestion: add button "close without saving" and add final warning window "if you proceed to exit gnumeric, changes made to opened files will not be saved".
Intelligence has nothing to do with it: not all pointing devices are 100% precise. For example, with a laptop pad, it is not very uncommon to end up pressing the wrong button by mistake. Therefore we want to avoid placing the self-destruct button right next to the intercom switch. We'll consider the suggestion.
well, it may be clearer if after "clear selection" the "save selected" button changes its label to "quit without saving". I think that would even be safer than still having a button that claims to save something when it doesn't.
Created attachment 173945 [details] [review] Patch that changes the "Save selected" button label to "Discard changes" when no files have been selected to be saved This patch changes the "Save selected" button label to "Discard changes" when no files have been selected to be saved. However, there is a problem... The buttons resize themselves when this change occurs, which visually is not right. Any suggestions on solving this problem?
Comment on attachment 173945 [details] [review] Patch that changes the "Save selected" button label to "Discard changes" when no files have been selected to be saved You might use gtk_tree_selection_count_selected_rows instead of none_set. Avoid the button resize is not easy, and might be even worse. In some languages, the strings might be of quite different lengths. Not even sure that the dialog will not resize.
The dialog actually resize for me.
Sameer, you should also avoid gcc warnings such as: dialog-quit.c:166: warning: passing argument 1 of ‘go_widget_set_tooltip_text’ from incompatible pointer type
hmm, the gtk_tree_selection_count_selected_rows is full stupid. Forget it.
We currently have a row of 4 buttons: (Select all)(Clear Selection)(Save Selected)(Don't Quit) The first two are just selection handling. The last two are final decisions. Note that normally the "Don't Quit" or "Cancel" would be to the left of "Save". So that is in the wrong order. Problems with changing button sizes always occurs when one changes button text. I fond it much simpler to show all buttons and possibly just disable some. So I would suggest we create two rows of buttons: First row: (Select all)(Clear Selection) Second row: (Discard Changes)(Don't Quit)(Save Selected) [note the order of this second row matches the order in teh dialog we see when closing a single document window.] At any time (depending on the selection status) we should then have one of (Discard Changes) and (Save Selected) enabled. [One could argue that (Discard Changes) should always be enabled but we want to ensure that it cannot be accidentally chosen, so users have to first deselect all and then can use that button.]
Created attachment 173972 [details] [review] Patch to resolve this issue
Created attachment 173978 [details] [review] Updated patch Fixes issues with: Changelog Distinct names Select All label Replaced none_set with 'positive' files_set, to avoid double false issues... Proper tabification and whitespace
Created attachment 173979 [details] [review] Updated patch Previous patch touched another lines whitespace unnecessarily
Comment on attachment 173979 [details] [review] Updated patch There is no need for FileSetState. It is just a gboolean anyways.
Created attachment 173980 [details] [review] Updated patch Removed FileSetState
I have committed a slightly modified version of this patch. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Comment on attachment 173980 [details] [review] Updated patch Just as a note: it could be important to initialize files_set_state in files_set since there is no guarantee that foreach_is_file_set is ever called. (At this time we don't create the dialog if there are no files but it is better to be save than sorry.)