Re (IRC): 2.2.0 and auto-save
c.shoemaker at cox.net
Thu Jul 5 09:53:31 EDT 2007
On Thu, Jul 05, 2007 at 10:44:46AM +0200, Christian Stimming wrote:
> 14:40:57 <warlord> Hmm, are we going to have a 2.1.6?
> 16:21:25 <andi5> warlord: wrt 2.1.6, if we plan not to revert the
> auto-save feature, we might want to have another test version.... iff
> christian wants to extend / improve it.... if we just change the
> default to disabled auto-save, then i am fine with no 2.1.6 as well...
> 16:21:52 <warlord> andi5: ok
> I don't want to extend/improve the auto-save feature before 2.2.0 (not
> enough time available). For that reason I don't think we need another
> 2.1.6 but should plan for 2.2.0 on the weekend July 15th,
> It seems to me the "perfect" solution would be to have a separate
> save-to-checkpoint function as opposed to the save-to-working-file,
> with extra auto-restore questions at startup, as outlined here by Eric
> This would require major changes in our saving infrastructure, which
> I'm not going to do in the upcoming 1-3 months.
> As an aside, I'd like to point out that the current auto-save
> behaviour represents exactly how gnucash would behave with a
> database-backend currently, as explained here correctly
> But for 2.2.0 we have the following choices:
> #1: Auto-save-datafile is enabled by default, just with a different
> default value (5 minutes? 10 Minutes?), and the explanation dialog box
> pops up upon the very first auto-save activation. Users would have to
> into the preferences to disable this feature.
> #2: Auto-save-datafile will be enabled once, then on the explanation
> dialog box the user is asked whether she/he wants to have this
> enabled: "auto-save ... blabla ... Do you want to enable or disable
> this? [Enable] [Disable]"
> #3: Auto-save is disabled by default and users have to find out the
> Option by themselves to enable it. No extra dialog explanation will be
> shown for this option, neither after startup nor at activation time or
> whatever. Using this feature is therefore restricted to those users
> who happen to stumble upon this during browsing through the preferences.
> The feedback from gnucash-user clearly points toward #3. However, my
> main intention was to implement a feature that helps "the normal user"
> to decrease the negative outcome of when an error occurs. This boils
> down to the question what behaviour "the normal user" actually expects
> from gnucash. As a programmer I know that my way of understanding
> gnucash is probably rather different from what "the normal user" does.
> However, I'm not so sure whether the gnucash-user feedback talks more
> about "the normal user" expectation than what I would think of,
> because those subscribers are power-users just as we are. (For
> example, my wife says the new auto-save behaviour is just fine and
> understandable, whereas the abovementioned
> "restore-checkpoint-at-startup" behaviour would be utterly confusing
> for her - she never really understands what she is supposed to answer
> when a program asks at startup about "restoring whatever thingy is
> also there". I'm just saying we developers have to find a decision
> which doesn't necessarily conform with the majority of feedback on our
> mailing lists. Neither we ourselves nor even the users of our mailing
> lists might correspond "the normal user" in a representative way.
> Decisions, decisions...
> Following this way of thought I would decide for choice #1, leave
> as-is for 2.2.0. What do the other developers say?
For better or for worse, we've conditioned users (me included) to
expect that they can 1) open GnuCash, 2) make undesired changes for
the purposes of exploration or experimentation, 3) close GnuCash w/o
saving, and 4) re-open GnuCash with their data in exactly the state
they last saved it.
Purely as a matter of politeness, I think it would be rude to change
this behavior without any user action.
Given the current difficulty of implementing a
autosave-to-alternate-file behavior, I'd suggest the following:
#4) (a refinement of #2) Leave auto-save enabled by default, but change
the behavior slightly:
- When autosave triggers prompt the user with:
==== Auto-save ====
Do you want to auto-save your data file?
[some explanation of the implications;]
[explanation that this can be customized in Preferences]
[Yes, just this once] [Yes, always] [No, not right now *] [No, never]
Until either (a) the user sets something in the preferences, or (b) they
choose one of the always/never options, then this dialog should continue to
appear _every_ time the auto-save triggers.
- The original behavior is one click away (No, never).
- The fully automated auto-save behavior is one click away (Yes, always).
- It leaves the user the option of full control. (with or w/o further dialog)
- Even users that don't want autosave may appreciate the reminder to save
manually, (or they can avoid it, if not).
- It allows the use of the autosave feature even in cases where the user
wants to make unsaved changes.
In any case, I am against changing the default setting in a way that
requires long-time users to set a Preference in order to restore the
behavior they've become used to, and at least some find useful. OTOH,
I think auto-save is a very compelling feature we should make very
easy to enable.
So, I'm fine with #2, #3, or #4, but not with #1.
And, thanks for the nice feature, Christian. :)
More information about the gnucash-devel