Re (IRC): 2.2.0 and auto-save
John P. New
jnew at hazelden.ca
Thu Jul 5 11:23:11 EDT 2007
Speaking strictly as a user of GnuCash, I like the current auto-save as
implemented i.e. save-to-working-file; thanks, Christian!
I've never played around with a GnuCash file, decided I didn't like the
changes and closed without saving (but strangely enough, I do that with other
programs), but that's just me. I guess if I were intending to "play" with my
data file, I would either disable the auto-save or work on a backup copy of
the file (the latter probably the safer choice). On the other hand, I can see
the benefits of a save-to-checkpoint-file.
But, if I could put in my 2 cents, whatever the developers decide, please:
1) inform the user of any change in behaviour that could adversely affect
their data file (similar to Chris Shoemaker's option #4) , and
2) decide which method to use (save-to-working-file or
save-to-checkpoint-file) and stick with it. Nothing annoys me more than a
too-frequently-changing data file behaviour. If the developers are uncertain
as to which method will ultimately become permanent, I would say disable the
feature for 2.2.0
On July 5, 2007 04:44 am, 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?
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel