Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
On Sun, Jul 01, 2007 at 02:35:13PM +0200, Christian Stimming wrote: Once you install r16627 or higher (which will become 2.1.5), auto-save will be activated every 3 minutes by default (counting from the first change of your data, i.e. when the * appears in the title bar). The very first time this feature is run you will be shown an explanatory dialog that tells you where you can change the time interval or switch off this feature. That dialog won't be shown again. Does it save over your current working datafile? Or does it save a backup snapshot of the datafile that the next time you open gnucash after a crash gnucash will ask you if you want to open the backup or the real thing? The reason I ask is that gnucash does not include an undo feature, which I see as essential to having an autosave that overwrites your most recent working datafile. I fairly often try to import an OFX or QIF file, make a mistake or change my mind, quit without saving on purpose, then re-open the file to try again. Sometimes I do this with respect to reconciliation as well, because it's much easier to go back to the last known-good state than it is to try to figure out which things are half-done. If gnucash had undo I could see having an autosave that is on by default as a good feature, but without undo, I'd much rather see it save a copy (like all those tmp files gnucash makes that don't include business features) instead of overwriting the current working file. Right now the only chance a user has to undo things is to go back to the previously saved copy. --Beth Beth Leonard http://www.LeonardFamilyVideos.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: updated gnucash's french translation : fr.po (Second release)
Hello Christian, Thanks for updating the translation so fast. I did it so fast because I thank that Gnucash 2.1.5 was release the June, 30th. Yannick Christian Stimming write : Am Sonntag, 1. Juli 2007 00:59 schrieb Yannick LE NY: I send about 6 hours ago a new fr.po file but there was a new Merge latest translation updates for upcoming release on subversion and I have again some fuzzy strings and some strings that are not translated. Applied to SVN. Thanks a lot. I send you now the the second release for fr.po file this day. I hope that for gnucash 2.1.5, all the strings in the fr.po file will be up to date. Yes, there won't be any further string changes until 2.1.5 and (hopefully) 2.2.0. There had been some (very minor) changes in the last week(s) and that's what you've just received. Thanks for updating the translation so fast. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
Quoting Beth Leonard [EMAIL PROTECTED]: Does it save over your current working datafile? Or does it save a backup snapshot of the datafile that the next time you open gnucash after a crash gnucash will ask you if you want to open the backup or the real thing? In that sense: Yes, it does indeed save over the current working datafile, say, foo.xac. But the old datafile will be kept around as a time-stamped backup copy, say, foo.20070702121341.xac. This fact is admittedly not at all obvious. Nevertheless the older data does exist. However, from the time-stamped filenames you can't tell which one was saved by pressing save and which one by the current auto-save implementation. If gnucash had undo I could see having an autosave that is on by default as a good feature, but without undo, I'd much rather see it save a copy (like all those tmp files gnucash makes that don't include business features) instead of overwriting the current working file. Right now the only chance a user has to undo things is to go back to the previously saved copy. Hm... the problem here is that this would require major changes in how the file saving works, and also the program has to keep track not only of the book-dirty state but additionally of the book-manually-saved state (to distinguish whether the book has been auto-saved, or manually saved, or both). From a programmer's point of view this is hard. The main reason for me to implement this so quickly was that I discovered in the current way the implementation was surprisingly easy from a programmer's point of view. What I'm saying is that if the feature in the current form doesn't meet user's needs, we can very well disable this again... sorry for that. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: updated gnucash's french translation : fr.po (with the file)
2007/6/30, Christian Stimming [EMAIL PROTECTED]: Dear Yannik, thank you very much for this 100% complete translation! That has been a lot of work. I committed this to SVN so that it is in 2.1.5. Did you co-ordinate this work with the other recent translators? I've included them in CC; I guess they will contact you in case there needs to be any further coordination. But a complete translation is of course a great thing that has been achieved. Thanks again. Thanks for your job, Yannick, We can't use Vertimus[1] to translate GnuCash because I don't have SVN access to GnuCash's repository but you can send an email with your PO file to [EMAIL PROTECTED] (http://www.traduc.org/mailman/listinfo/gnomefr) for review. This method is useful to avoid some mistakes like these : Si cette option est cochée, GnuCash montre une explicatioin de la fonction de sauvegarde automatique lors du premier lancement de cette fonctionnalité. Autrement aucune explication supplémentaire n'est montrée. montre - affiche explicatioin - explication last sentence: Dans le cas contraire, aucune explication ne sera affichée. Regards, Stéphane [1] : http://gnomefr.traduc.org/suivi/ PS : I spotted some others mistakes if you want a review, just send an email to the ml :) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
Beth Leonard [EMAIL PROTECTED] writes: On Sun, Jul 01, 2007 at 02:35:13PM +0200, Christian Stimming wrote: Once you install r16627 or higher (which will become 2.1.5), auto-save will be activated every 3 minutes by default (counting from the first change of your data, i.e. when the * appears in the title bar). The very first time this feature is run you will be shown an explanatory dialog that tells you where you can change the time interval or switch off this feature. That dialog won't be shown again. Hi Christian, Emacs auto-saves every n seconds or m keystrokes. In addition to auto-saving every 180 seconds, I'd also suggest auto-saving every 10 new or updated entries or so. That, too, should be configurable. Emacs and other programs I've seen auto-save into a separate file. I'd strongly suggest, and it would be greatly appreciated by the user community, that the hard work be done to make it so. You will end up surprising a lot of folks (not in a good way) by auto-saving over the original file. Thanks for adding this feature, by the way. It is an excellent one. I've wished I had it in the past ;-). -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
Hi, Eric Ladner [EMAIL PROTECTED] writes: Kind of like how 'vi' does it too. Here's the rough logic... (on startup) if (alternate file exists) // something went wrong.. prompt user for option of reloading saved checkpoint if (user says yes) load checkpoint else delete file (timed) save to alternate file if (user saves file) delete checkpoint (on exit) if (not saved) prompt user to save if (user says yes) save file delete checkpoint That way, you're not saving over the official data file, but saving to an alternate file that always has the same name (account.ckpt maybe). When loading account account, if a checkpoint exists, something bad happened and you can restore to that checkpoint, or just load the original file (rollback all the way to last session). Unfortunately the way GnuCash/QOF works makes this sort of autosave process very difficult to implement. QOF tries to make it's data look like a database, not a data file, so it really does abstract out these things. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Check Printing - Addresses
On Mon, Jul 02, 2007 at 04:43:31PM -0400, Derek Atkins wrote:
Andrew Sackville-West [EMAIL PROTECTED] writes:
ISTM that there are a number of situations where this issue comes up
with gnucash: we don't know which split is the one to use for
purpose x. I guess it comes up in sched-x a bit and in other places
where the display of information is not necessarily done in a way that
people would expect. For example, a check with two splits: from
the data's perspective, no split is more important than any other. And
I think that's as it should be. And for most uses, its totally
appropriate. BUt for check printing, or deciding which split to
display in a register-neutral situation like displaying scheduled
transactions before commit, the splits do matter, at least
somewhat. In the check situation its obvious: the one that matters is
the local one; the one that relates to the checking account.
What's the definition of primary split? Is it the first split you
create? Is it the first split tied to the account register? What
about for transactions created through other methods, like the transfer
dialog or an importer -- which split is primary?
This is based on my *very limited*
understanding, BTW, so feel free to educate me in whatever manner is
expedient... (including STFU...)
Its purely arbitrary in that for almost every purpose it doesn't
matter. But for some purposes -- specifically in this context for the
purpose of attaching additional information to a transaction, such as
an address -- it does matter. Simply use the register that is
used to create the transaction. For an invoice payment, the register the
transaction is entered into is A/{R,P} (but maybe my assumption is wrong
there). The other split is checking (could be others, I know). When
the payment is printed, the printing engine can look for a primary
split, and if that exists, and has additional information attached to
it, it could be printed as well. With an invoice payment, there is
owner information on the A/{R,P} side that could be used to grab that
address, or account number, or whatever.
It may be useful in other areas where there is a decision to be made
regarding which split to show, but I don't know. There was another
thread recently about why do we see every split in the sched-x
dialog, why not just checking. In that situation, if the sched-x was
created within the context of the checking register, then the checking
split was marked as the primary and it would make sense to display
that one split only (unless the transaction was selected and
expanded).
What is to prevent adding a Primary split field to transactions?
[...]
I still don't see how the primary split is useful.
I honestly don't know either, but it was an idea. The other
alternative, for a more feature rich check printing option would be to
walk through *all* the splits looking for owner information so that it
could be incorporated into the print, but that moves the logic from
the data level to the printing engine, which may not be a good
thing. By attaching it to the data, you can say this split has
additional information that may be useful for this transaction.
There might still (somehow?) be ambiguous situations. With a
primary split, then its easy: look at the primary split (if it
exists) and check for owner (is that the right term) information and
if that exists grab it and splat it onto the check. All other cases,
it simply prints a check as it currently is.
Another possible added bonus of this idea: invoice numbers printed on checks
without editing the fields.
the way I see it, it allows an opportunity to dis-ambiguate the data
if that's a benefit in a particular situation without having any
effect on the validity of the data. If the primary split is not set
(from old data, say) or there is no other information associated with
the primary split, then there is nothing lost. The bonus information
is simply not available.
thinking aloud
A
p.s. yes I'm aware that if this idea goes anywhere, I'd have to code
it... and I'm willing to learn. And I know it would a many tentacled
solution (Ramen).
signature.asc
Description: Digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: PATCH - QofCollection to be a GObject
Updated PATCH, it fixes some problems not finished, but now it works
with TRUNK and the resent 2.1.5 release.
El 27/06/07, Daniel Espinosa [EMAIL PROTECTED] escribió:
I've managed to convert QofCollection to a GObject. The API for this
object is unchanged, the only affectation was QofInstance, to set/get
its property collection from a gpointer to a GObject.
--
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (entrámite, pero para los
cuates: LIBRE)
--
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (entrámite, pero para los
cuates: LIBRE)
Index: lib/libqof/qof/qofinstance.c
===
--- lib/libqof/qof/qofinstance.c (revisión: 16247)
+++ lib/libqof/qof/qofinstance.c (copia de trabajo)
@@ -145,12 +145,13 @@
g_object_class_install_property
(object_class,
PROP_COLLECTION,
- g_param_spec_pointer (collection,
+ g_param_spec_object (collection,
Object Collection,
A collection of like objects of which this
particular object is amember. E.g.. A
collection of accounts, or a collection of
splits.,
+ QOF_TYPE_COLLECTION,
G_PARAM_READWRITE));
g_object_class_install_property
@@ -363,7 +364,7 @@
g_value_set_boxed(value, priv-guid);
break;
case PROP_COLLECTION:
-g_value_set_pointer(value, priv-collection);
+g_value_set_object(value, priv-collection);
break;
case PROP_BOOK:
g_value_set_object(value, priv-book);
@@ -421,7 +422,7 @@
qof_instance_set_guid(inst, g_value_get_boxed(value));
break;
case PROP_COLLECTION:
-qof_instance_set_collection(inst, g_value_get_pointer(value));
+qof_instance_set_collection(inst, (QofCollection*) g_value_get_object(value));
break;
case PROP_BOOK:
qof_instance_set_book(inst, g_value_get_object(value));
Index: lib/libqof/qof/qofid.c
===
--- lib/libqof/qof/qofid.c (revisión: 16247)
+++ lib/libqof/qof/qofid.c (copia de trabajo)
@@ -33,8 +33,14 @@
static QofLogModule log_module = QOF_MOD_ENGINE;
static gboolean qof_alt_dirty_mode = FALSE;
-struct QofCollection_s
+static guint id_hash (gconstpointer key);
+static gboolean id_compare(gconstpointer key_1, gconstpointer key_2);
+
+typedef struct _QofCollectionPrivate QofCollectionPrivate;
+
+struct _QofCollectionPrivate
{
+
QofIdTypee_type;
gboolean is_dirty;
@@ -42,6 +48,176 @@
gpointer data; /* place where object class can hang arbitrary data */
};
+enum {
+ PROP_0,
+ PROP_DIRTY,
+ PROP_E_TYPE
+};
+
+#define GET_PRIVATE(o) \
+ (G_TYPE_INSTANCE_GET_PRIVATE ((o), QOF_TYPE_COLLECTION, QofCollectionPrivate))
+
+static void qof_collection_class_init(QofCollectionClass *klass);
+static void qof_collection_finalize (GObject *object);
+static void qof_collection_get_property (GObject *object, guint prop_id, GValue *value, GParamSpec *pspec);
+static void qof_collection_set_property (GObject *object, guint prop_id, const GValue *value, GParamSpec *pspec);
+
+static GObjectClass *parent_class = NULL;
+
+static void qof_collection_class_init(QofCollectionClass *klass)
+{
+GObjectClass *object_class = G_OBJECT_CLASS(klass);
+
+ parent_class = g_type_class_peek_parent (klass);
+
+ object_class-finalize = qof_collection_finalize;
+object_class-set_property = qof_collection_set_property;
+object_class-get_property = qof_collection_get_property;
+
+g_type_class_add_private(klass, sizeof(QofCollectionPrivate));
+
+g_object_class_install_property
+ (object_class,
+ PROP_E_TYPE,
+ g_param_spec_string (e_type,
+ type,
+ The object's string type.,
+ NULL,
+ G_PARAM_READWRITE));
+
+
+g_object_class_install_property
+(object_class,
+ PROP_DIRTY,
+ g_param_spec_boolean (dirty,
+ Object Dirty,
+ This flag is set to TRUE if the object has
+ unsaved changes.,
+ FALSE,
+ G_PARAM_READWRITE));
+
+
+
+}
+
+static void
+qof_collection_init (QofCollection *col)
+{
+QofCollectionPrivate *priv;
+
+priv = GET_PRIVATE(col);
+ priv-e_type = NULL;
+ priv-hash_of_entities = g_hash_table_new (id_hash, id_compare);
+ priv-data = NULL;
+ priv-is_dirty = FALSE;
+
+}
+
+static void
+qof_collection_finalize (GObject *object)
+{
+QofCollectionPrivate *priv;
+ QofCollection* col = QOF_COLLECTION (object);
+
+ priv = GET_PRIVATE(object);
+
Custom reports / [ I'd like to create an applet for gnucash ]
Hello, Reading the gnucash-devel archive, I recognised the following problem: I might not use gnucash the way it is wanted... When I open gnucash it opens also about 6 reports and the data is inserted since 1.1.06, where I have also many private things, like many entries for supermarket (simple imported from my online banking export ofx). So there is many data processed and open gnucash takes more than a minute on my 1400 MHz Notebook with 1.2 GB RAM. So my suggestion was a way to simple insert _one_ (or three, but not many) transactions into gnucash at a time where I don't want to see all the reports and avoid the long start time just for inserting one transaction. I think what Martin wants is not so much an applet, but gnucash starting quicker -- and like me, he has a few reports that are calculated every time, so that starting gnucash takes forever. And if he is like me, then I suspect that he doesn't really want to calculate those reports everytime: some of them I only want to view only once a month or so, but I had them always included, because closing the report loses the options (and e.g. with the balance sheet selecting the same accounts to include and exclude every time is nigh on impossible). I guess the actual problem that Martin has is: custom reports are too obscure! I've found out how to do them now: generate the report as usual, rename the report (report options/general/Report Name:), and press Ok or Apply; now the 'Add Report' toolbar button becomes active. Click 'Add Report', and the next time you start gnucash the report will appear under the Reports/Custom menu. So then you can close the report window, and the next time you start gnucash it will not be generated, so gnucash will start up more quickly -- you can regenerate it wen you want from the custom reports menu (and probably close it again before quitting gnucash, or gnucash would still start slowly). So -- (1) the manual does not mention the possibility to save custom reports, it would be nice if it does (in the section about reports) (2) Even when I had figured out that it was possible to save custom reports, I still could not find how to: because having to rename the report before you are offered the opportunity to save it is counter-intuitive. What would probably be a better user experience is that the 'Add Report' button is always active, but that for a report that is not renamed it brings up a pop-up window asking you for a name to save the report under. And on a related matter: if you rename a report, and then rename it back, then the 'Add Report' button is still active. Should it be? Best regards, Jeroen Nijhof ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Custom reports / [ I'd like to create an applet for gnucash ]
Jeroen Nijhof [EMAIL PROTECTED] writes: I guess the actual problem that Martin has is: custom reports are too obscure! I've found out how to do them now: generate the report as usual, Yup! So -- (1) the manual does not mention the possibility to save custom reports, it would be nice if it does (in the section about reports) New text as a patch against gnome-docs is welcome. (2) Even when I had figured out that it was possible to save custom reports, I still could not find how to: because having to rename the report before you are offered the opportunity to save it is counter-intuitive. What would probably be a better user experience is that the 'Add Report' button is always active, but that for a report that is not renamed it brings up a pop-up window asking you for a name to save the report under. Presently, it should complain that the report needs to be renamed, but it does not at that point prompt you for the new name. And on a related matter: if you rename a report, and then rename it back, then the 'Add Report' button is still active. Should it be? Probably not. The reports system needs a major overhaul, but this aspect of it is one of the more annoying parts, true. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpu0pWmrdMAd.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: PATCH - QofCollection to be a GObject
Daniel Espinosa [EMAIL PROTECTED] writes: Updated PATCH, it fixes some problems not finished, but now it works with TRUNK and the resent 2.1.5 release. I voiced this on IRC, but should mention it here... I've only cursorily reviewed the patch; regardless, I don't think it should be applied to trunk until after 2.2 is branched or released. I don't think any unnecessary infrastructure changes need to be applied at this point. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpsidey2we7i.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
On Tue, Jul 03, 2007 at 01:50:30PM -0400, Derek Atkins wrote: Unfortunately the way GnuCash/QOF works makes this sort of autosave process very difficult to implement. QOF tries to make it's data look like a database, not a data file, so it really does abstract out these things. Gnucash does have a save as... menu item. Is it possible for the autosave to hook into that set of calls, insead of the save in order to implement the logic Eric outlines below? I do like that logic for auto-save functionality. If this is difficult, allowing the user to turn off auto-save is sufficient. --Beth Eric Ladner [EMAIL PROTECTED] writes: Kind of like how 'vi' does it too. Here's the rough logic... (on startup) if (alternate file exists) // something went wrong.. prompt user for option of reloading saved checkpoint if (user says yes) load checkpoint else delete file (timed) save to alternate file if (user saves file) delete checkpoint (on exit) if (not saved) prompt user to save if (user says yes) save file delete checkpoint That way, you're not saving over the official data file, but saving to an alternate file that always has the same name (account.ckpt maybe). When loading account account, if a checkpoint exists, something bad happened and you can restore to that checkpoint, or just load the original file (rollback all the way to last session). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Beth Leonard http://www.LeonardFamilyVideos.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
Unfortunately Save As repoints the current active datafile, so hooking into there would change your datafile out from under you. So, no, we can't use that functionality directly. -derek Quoting Beth Leonard [EMAIL PROTECTED]: On Tue, Jul 03, 2007 at 01:50:30PM -0400, Derek Atkins wrote: Unfortunately the way GnuCash/QOF works makes this sort of autosave process very difficult to implement. QOF tries to make it's data look like a database, not a data file, so it really does abstract out these things. Gnucash does have a save as... menu item. Is it possible for the autosave to hook into that set of calls, insead of the save in order to implement the logic Eric outlines below? I do like that logic for auto-save functionality. If this is difficult, allowing the user to turn off auto-save is sufficient. --Beth Eric Ladner [EMAIL PROTECTED] writes: Kind of like how 'vi' does it too. Here's the rough logic... (on startup) if (alternate file exists) // something went wrong.. prompt user for option of reloading saved checkpoint if (user says yes) load checkpoint else delete file (timed) save to alternate file if (user saves file) delete checkpoint (on exit) if (not saved) prompt user to save if (user says yes) save file delete checkpoint That way, you're not saving over the official data file, but saving to an alternate file that always has the same name (account.ckpt maybe). When loading account account, if a checkpoint exists, something bad happened and you can restore to that checkpoint, or just load the original file (rollback all the way to last session). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Beth Leonard http://www.LeonardFamilyVideos.com -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
A little problem I have with this idea is that it takes several minutes to save my file. With 16K transactions, there is just too much data to grind out. I need to get my data into a database, I think. Of course I'm just using a 1.8 GHz P6. It would help if I had a modern computer. Bill Wohler wrote: Beth Leonard [EMAIL PROTECTED] writes: On Sun, Jul 01, 2007 at 02:35:13PM +0200, Christian Stimming wrote: Once you install r16627 or higher (which will become 2.1.5), auto-save will be activated every 3 minutes by default (counting from the first change of your data, i.e. when the * appears in the title bar). The very first time this feature is run you will be shown an explanatory dialog that tells you where you can change the time interval or switch off this feature. That dialog won't be shown again. Hi Christian, Emacs auto-saves every n seconds or m keystrokes. In addition to auto-saving every 180 seconds, I'd also suggest auto-saving every 10 new or updated entries or so. That, too, should be configurable. Emacs and other programs I've seen auto-save into a separate file. I'd strongly suggest, and it would be greatly appreciated by the user community, that the hard work be done to make it so. You will end up surprising a lot of folks (not in a good way) by auto-saving over the original file. Thanks for adding this feature, by the way. It is an excellent one. I've wished I had it in the past ;-). ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
keith [EMAIL PROTECTED] writes: A little problem I have with this idea is that it takes several minutes to save my file. With 16K transactions, there is just too much data to grind out. I need to get my data into a database, I think. Of course I'm just using a 1.8 GHz P6. It would help if I had a modern computer. Ouch. OK, that gives me an idea--add another option to wait until Gnucash is idle n minutes before auto-saving. That way, Gnucash will auto-save while you're making coffee, for example. For me, saving takes about four seconds. It's not enough to cause hardship, but it would be a pain while I was actively entering transactions. So, I might imagine a configuration like (every 5 minutes or 10 transactions) and 1 minute idle. That said, I would take auto-save over original file over no auto-save at all. But it sounds like it would still be a good idea to keep an alternate implementation in the queue. Huge kudos, as always, to the Gnucash team for keeping us Windows free. For you Yanks, happy Fourth! -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Auto-Saving implemented in r16227 (to become 2.1.5) - Feedback wanted
I think either something as Wouter described, bury this in the settings and give ample explanation for what it does, or disabling it completly (at least in the stable versions) until it's really ready for normal use is needed. My gut feeling is to do the latter. While it's useful for some it sounds like it could have adverse and unexpected effects that outweigh it's benefits for people if enabled. 2007/7/3, Wouter van Marle [EMAIL PROTECTED]: [auto-save overwrites current working file] The main reason for me to implement this so quickly was that I discovered in the current way the implementation was surprisingly easy from a programmer's point of view. What I'm saying is that if the feature in the current form doesn't meet user's needs, we can very well disable this again... sorry for that. Auto-save sounds very useful to me as well. Maybe keep it disabled by default, allowing users to enable it (tick-mark in the settings dialogues), with strong warning about this over-writing behaviour. Indeed I agree with the grandparent that auto-save should not overwrite the current file (can't the auto-save function, when calling the save function, automatically add .autosave to the file name or so? I haven't read the source so no idea whether it is possible). Personally I don't experiment very often; and when I do I usually first save a copy to a different name, and play with that. Wouter. Christian ___ gnucash-user mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-user mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. -- Ian Lewis [EMAIL PROTECTED] http://www.ianlewis.org/ http://jsxe.sourceforge.net ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash 2.1.5 Released
The windows binary should be ready tomorrow - I'm running a bit behind this time. Nathan ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
