Bug 380641 - Improve save behavior of scripts on quit
Summary: Improve save behavior of scripts on quit
Status: REPORTED
Alias: None
Product: rkward
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: RKWard Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-23 09:50 UTC by RKWard Team
Modified: 2011-10-24 07:18 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description RKWard Team 2011-10-23 09:50:30 UTC
-- Originally posted by (AT sourceforge.net): nalimilan --

-- This ticket was imported from http://sourceforge.net/p/rkward/feature-requests/107 on 2017-05-31 14:48:58 +0100 --
When you close a text file with unsaved changes, you get a confirmation dialog asking whether to really close it, with choices Yes and No. This is very bad WRT usability, because the choices are very generic, and you have to read carefully the question to decide what to do: many programs do it the other way, by asking whether to save changes or not.

I suggest this dialog uses explicit button labels, like "Save", "Discard" and "Don't quit", just like what happens when you close a workspace. The question should be "Do you want to save changes?" rather than the contrary, to match the same pattern as closing workspaces.

By the way, the new distinction between "Discard" and "Don't quit" should allow you to close RKward and save changes in modified scripts in one go. At the moment, if there's one script with unsaved changes, you can only cancel the quit, save, and retry. Another point is that RKward should handle script files first, and the workspace afterwards, since saving the workspace takes time: if you save the workspace, and then notice you have unsaved changes in a script and you no longer want to quit, you've wasted time saving the workspace.
Comment 1 Thomas Friedrichsmeier 2011-10-24 07:18:17 UTC
Yes, this really needs an overhaul. Thanks for your suggestions.

I'm moving it to our RFE-tracker, though.
Comment 2 Thomas Friedrichsmeier 2011-10-24 07:18:17 UTC
- **labels**: 673590 -->