Re: A crash in business functions
Nigel Titley [EMAIL PROTECTED] writes:
unnamed port: In expression gnc:id-book:
unnamed port: Unbound variable: gnc:id-book
I am sorry, I cannot find gnc:id-book in the current source code. Maybe
this is in ~/.gnucash/books?
[EMAIL PROTECTED]:~/src-new/gnucash$ find . -name '*.*' -exec egrep -i
id-book
{} \; -ls
* business-prefs.scm: register a kvp-option generator for
gnc:id-book
1753345 184 -r--r--r-- 1 nigeltitley 181710 Mar 20 23:34
./.svn/text-base/ChangeLog.2002.svn-base
s/gnc:id-book/QOF-ID-BOOK-SCM/g
1753352 832 -r--r--r-- 1 nigeltitley 846282 Mar 20 23:35
./.svn/text-base/ChangeLog.2006.svn-base
Which confirms Andreas' assertion that gnc:id-book isn't in the
sources anywhere.
-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: Ping: Re: [patch] FIx loan druid when auto_decimal is enabled
Jerry Quinn [EMAIL PROTECTED] writes: Derek Atkins wrote: I haven't. I don't know if Josh has. Has anyone tested this patch? Have you? Does it work? It works as expected for me when I test it, both with auto-decimal enabled and disabled. What else would you like me to do? Convince JSled to look at it? He knows that code better than I do. The patch looks okay to me, but I don't understand the code.. -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: A crash in business functions
Which confirms Andreas' assertion that gnc:id-book isn't in the sources anywhere. Yes, having looked at my email this morning, this was what I realised (it was pretty late when I emailed last night) So we are back to the original question. What caused the crash? What more information can I give you (and where did that * gnc:id-book come from?) Nigel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: A crash in business functions
Quoting Nigel Titley [EMAIL PROTECTED]: Which confirms Andreas' assertion that gnc:id-book isn't in the sources anywhere. Yes, having looked at my email this morning, this was what I realised (it was pretty late when I emailed last night) So we are back to the original question. What caused the crash? What more information can I give you (and where did that * gnc:id-book come from?) I dont know. An old installation? Some old files lying around in some directory (or some DIFFERENT directory)? I see no reference to gnc:id-book anywhere so I can only assume some leftovers from a previous version lying around and co-mingling with your current trunk. Nigel -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: A crash in business functions
On Tue, Mar 27, 2007 at 03:44:02PM +0100, Nigel Titley wrote: Which confirms Andreas' assertion that gnc:id-book isn't in the sources anywhere. Yes, having looked at my email this morning, this was what I realised (it was pretty late when I emailed last night) So we are back to the original question. What caused the crash? What more information can I give you (and where did that * gnc:id-book come from?) Probably files left-over in your install directory, or picked up by the application during load. What did you use for a --prefix? and can you blow away the old install and redo the `make install`? -chris Nigel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: A crash in business functions
Probably files left-over in your install directory, or picked up by the application during load. What did you use for a --prefix? and can you blow away the old install and redo the `make install`? Hmm, yes, that's a good idea. I'll try when I get back home. (--prefix=/opt/gnucash so I can blow away the whole thing). Nigel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Ping: Re: [patch] FIx loan druid when auto_decimal is enabled
On Tue, March 27, 2007 8:05 am, Derek Atkins wrote: Jerry Quinn [EMAIL PROTECTED] writes: Derek Atkins wrote: I haven't. I don't know if Josh has. Has anyone tested this patch? Have you? Does it work? It works as expected for me when I test it, both with auto-decimal enabled and disabled. What else would you like me to do? Convince JSled to look at it? He knows that code better than I do. The patch looks okay to me, but I don't understand the code.. I'd be happy to, but I'm out of town on business this week, and am not really in a place to (comfortably) apply the patch. I'll take a closer look next week. Can you attach the patch to the bug, please? -- ...jsled http://asynchronous.org/ | a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Inquiry]GNUCash SoC - Implementing Undo
akintayo holder wrote: Hi, I agree with your points, except for the single GList. I think Undo needs to be local in context. In other words if I Undo from a given register, it should only undo the operations made from that view even if they do not just impact this view. So it must be possible to associate an undo with a view/account. I don't think the idea of a view-local undo will work. Suppose you have a transaction as follows: Account A: +100 Account B: -100 (1) Then you change it, from the Account B view, to: Account C: +100 Account B: -100 (2) Then you change it, from the Account C view, to: Account C: +100 Account D: -100 (3) Then you change it, from the Account C view, to: Account C: +200 Account D: -200 Now suppose you hit undo in account B. What exactly do you expect to happen? Should edits (1)-(3) be undone at once? Or only edit (1), without undoing (2) and (3)? Or none of them? What if you made some other changes in account C after (2) and (3)? Should they be undone as well? I agree with Derek that operations should be undone in the order in which they were performed, i.e., at the book level, not the account level. Alternatively, if a local undo operation is absolutely necessary, then it should be associated with transactions, not with accounts (i.e., undo the last change in the highlighted transaction). -- Peter I would prefer to maintain list for each account, rather than search a global list for undos associated with the type/view. I do see a problem with this approach, but the headache due to multiple lists seems equivalent to the managing a global list. In the global case you would need to be aware of the view/account and maintain positions in the list for each of these, and similar complexity when updating the lists etc. With Import I would assign it to the containing Account Hierarchy. I would be tempted to do so with most dialogs like Price Editor and Security Editor. Reports would be treated to its own GList, as if it were an account. Akintayo On 3/25/07, Derek Atkins [EMAIL PROTECTED] wrote: Um, but which account do you associate it with? When you Undo don't you want to undo from the UI, not on a per-account basis? And what about something like a QIF Import, which really should be an atomic do/undo object? Where would you store that info? Keep in mind that Undo does NOT need to be persistent. As soon as you quit the application it's perfectly reasonable to lose your ability to undo. Think about the emacs undo operations as a decent model. Or Open Office. Personally I STILL think it's better to just have a GList in the session and base your Undo list on that. I think putting it into the account would just cause much more confusion and probably not solve all the problems. Keep in mind that users want to undo changes that aren't necessarily transaction input! You might want to undo, e.g., a PriceDB entry, or a new Customer, or an Invoice entry, or... Lots of things that don't touch Accounts. Just something to think about. Getting the architecture right is important to success. -derek akintayo holder [EMAIL PROTECTED] writes: The reason I like Undo being associated with an account is the simple way in which to enforce context. So an Undo could not impact a hidden account in an unexpected way. Since accounting transactions affect at least two accounts, grouping by account was more of an interface concession. On 3/23/07, Derek Atkins [EMAIL PROTECTED] wrote: I'm not convinced that the Undo feature belongs to an account. There are other (non-account-based) operations that should be undoable, such as changes to the PriceDB, direct Transfer Dialog entries, or even changes made via File - Import. I think the Undo log should be part of the Book (or maybe Session), and there needs to be a way to group operations together into the atomic undo operations. The rest of your statement I agree with, that Undo should check that the state is correct before it allows the undo.. Same for Redo. Thanks, -derek akintayo holder [EMAIL PROTECTED] writes: Hi, Its seems that with respect to multi-user transactions and Undo, the first step would be to enforce this rule; A transaction cannot be Undone if the state of the record does not match the state after the original transaction had completed. For example, you can only Undo an account creation if the account was still empty. I would implement the update history as an account associated data structure which is stored in memory. A local history would allow undos to be performed by simply traversing the account's list and picking the next change. Anyway, this approach would mean that updates from other users are not aggregated in one list. Thanks for the comments. Akintayo
Re: A crash in business functions
Nigel Titley wrote: Probably files left-over in your install directory, or picked up by the application during load. What did you use for a --prefix? and can you blow away the old install and redo the `make install`? Hmm, yes, that's a good idea. I'll try when I get back home. (--prefix=/opt/gnucash so I can blow away the whole thing). That seems to have fixed it. Thanks for the suggestion. Nigel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Again font size when printing (help!!!)
Hello , I am really frustrated with the way GnuCash handles the printing of reports. I'm an end-user I don't want to learn Scheme to get what I want. And if I can believe the questions I found in the mailing list there are bunch of us. I have searched the net and the mailing list and all I get are unanswered questions. Try this or try that, sometimes it works, sometimes it won't. I have even found a posting of programmers saying they are giving up on this problem. Yes I tried to change print-session.c no luck, it will not work. I'm trying to get this to work for 4 days now and being a small-business owner I really do not have the time to figure this out. Its a shame GnuCash is a really nice program. I like using it, but printing is hell. Is there anyone how knows exactly how this printing works? Please programmers! I do not want feature X or option Y I just want to get my financial data on a piece of paper and please bear in mind that I'm not blind and my storage is limited, I don't want huge fonts. I know that my tone of voice probably will not invite you to answer. Sorry for that, I need to get my frustration out. I'm feeling much better now thanks :-) Now my questions. When I push the print button what happens? Which files are used and in what order? Where are the variables located? And naturally where besides print-session.c are font sizes defined? Thanks, Rob (2old). ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[PATCH] Separate counters for bills and invoices
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Invoices and bills were sharing the same counter. Unfortunately it's a
legal requirement in Belgium to have a separate numbering for those.
This patch fixes that. There was already a request for this on bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=327218. I attached my patch
there too.
This is my first patch for gnucash. Don't shoot me for forgetting about
something ;)
Please CC me, I'm not on this list.
Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGCHGyrCFWJqEhh1cRAmXuAJwMX3hfBa31LVcebKKCAJIj8h6/7gCbBI0r
TNrDXMr69842tTMBRgGbhVw=
=Yj5l
-END PGP SIGNATURE-
Index: src/business/business-core/gncInvoiceP.h
===
--- src/business/business-core/gncInvoiceP.h (revision 15756)
+++ src/business/business-core/gncInvoiceP.h (working copy)
@@ -32,9 +32,10 @@
#include Account.h
#include Transaction.h
#include gnc-lot.h
+#include gncOwner.h
gboolean gncInvoiceRegister (void);
-gint64 gncInvoiceNextID (QofBook *book);
+gint64 gncInvoiceNextID (QofBook *book, GncOwner *owner);
void gncInvoiceSetPostedAcc (GncInvoice *invoice, Account *acc);
void gncInvoiceSetPostedTxn (GncInvoice *invoice, Transaction *txn);
void gncInvoiceSetPostedLot (GncInvoice *invoice, GNCLot *lot);
Index: src/business/business-core/gncInvoice.c
===
--- src/business/business-core/gncInvoice.c (revision 15756)
+++ src/business/business-core/gncInvoice.c (working copy)
@@ -1587,7 +1587,19 @@
return qof_object_register (gncInvoiceDesc);
}
-gint64 gncInvoiceNextID (QofBook *book)
+gint64 gncInvoiceNextID (QofBook *book, GncOwner *owner)
{
- return qof_book_get_counter (book, _GNC_MOD_NAME);
+ gint64 nextID;
+ switch(gncOwnerGetType(owner)) {
+case GNC_OWNER_CUSTOMER:
+nextID = qof_book_get_counter (book, gncInvoice);
+break;
+case GNC_OWNER_VENDOR:
+ nextID = qof_book_get_counter (book, gncBill);
+ break;
+default:
+ nextID = qof_book_get_counter (book, _GNC_MOD_NAME);
+ break;
+ }
+ return nextID;
}
Index: src/business/business-gnome/dialog-invoice.c
===
--- src/business/business-gnome/dialog-invoice.c (revision 15756)
+++ src/business/business-gnome/dialog-invoice.c (working copy)
@@ -344,8 +344,12 @@
/* Check the ID; set one if necessary */
res = gtk_entry_get_text (GTK_ENTRY (iw-id_entry));
if (safe_strcmp (res, ) == 0) {
+/* Invoices and bills have separate counters.
+ Therefore we pass the GncOwer to gncInvoiceNextID
+ so it knows whether we are creating a bill
+ or an invoice. */
string = g_strdup_printf (%.6 G_GINT64_FORMAT,
- gncInvoiceNextID(iw-book));
+ gncInvoiceNextID(iw-book, (iw-owner)));
gtk_entry_set_text (GTK_ENTRY (iw-id_entry), string);
g_free(string);
}
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Again font size when printing (help!!!)
On Mon, 26 Mar 2007, two old wrote: I'm not blind and my storage is limited, I don't want huge fonts. I know little about the reports, but I do know that you can save them as HTML. Do that, save them as HTML, then you can put them in any HTML editor and modify them as you wish, including changing the font size. In fact you probably will be able to change the font size in the browser alone without an editor. -Ariel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Inquiry]GNUCash SoC - Implementing Undo
In the scenario given, It would not be possible to undo from account B as the state of the transaction would've been modified elsewhere. I think it is the lesser of all evils, as a global list may involved undoing a transaction that isn't visible or switching to a different account view. If I were to Undo (3) I would need to show Account C or D by jumping to them, or I could just undo the change quietly. Both seem less than friendly to me. A transaction based approach would cause issues with deletes, and bobbled operations where you cannot find the transaction you just modified usually because you don't know which one it is. On 3/27/07, Peter Selinger [EMAIL PROTECTED] wrote: akintayo holder wrote: Hi, I agree with your points, except for the single GList. I think Undo needs to be local in context. In other words if I Undo from a given register, it should only undo the operations made from that view even if they do not just impact this view. So it must be possible to associate an undo with a view/account. I don't think the idea of a view-local undo will work. Suppose you have a transaction as follows: Account A: +100 Account B: -100 (1) Then you change it, from the Account B view, to: Account C: +100 Account B: -100 (2) Then you change it, from the Account C view, to: Account C: +100 Account D: -100 (3) Then you change it, from the Account C view, to: Account C: +200 Account D: -200 Now suppose you hit undo in account B. What exactly do you expect to happen? Should edits (1)-(3) be undone at once? Or only edit (1), without undoing (2) and (3)? Or none of them? What if you made some other changes in account C after (2) and (3)? Should they be undone as well? I agree with Derek that operations should be undone in the order in which they were performed, i.e., at the book level, not the account level. Alternatively, if a local undo operation is absolutely necessary, then it should be associated with transactions, not with accounts (i.e., undo the last change in the highlighted transaction). -- Peter I would prefer to maintain list for each account, rather than search a global list for undos associated with the type/view. I do see a problem with this approach, but the headache due to multiple lists seems equivalent to the managing a global list. In the global case you would need to be aware of the view/account and maintain positions in the list for each of these, and similar complexity when updating the lists etc. With Import I would assign it to the containing Account Hierarchy. I would be tempted to do so with most dialogs like Price Editor and Security Editor. Reports would be treated to its own GList, as if it were an account. Akintayo On 3/25/07, Derek Atkins [EMAIL PROTECTED] wrote: Um, but which account do you associate it with? When you Undo don't you want to undo from the UI, not on a per-account basis? And what about something like a QIF Import, which really should be an atomic do/undo object? Where would you store that info? Keep in mind that Undo does NOT need to be persistent. As soon as you quit the application it's perfectly reasonable to lose your ability to undo. Think about the emacs undo operations as a decent model. Or Open Office. Personally I STILL think it's better to just have a GList in the session and base your Undo list on that. I think putting it into the account would just cause much more confusion and probably not solve all the problems. Keep in mind that users want to undo changes that aren't necessarily transaction input! You might want to undo, e.g., a PriceDB entry, or a new Customer, or an Invoice entry, or... Lots of things that don't touch Accounts. Just something to think about. Getting the architecture right is important to success. -derek akintayo holder [EMAIL PROTECTED] writes: The reason I like Undo being associated with an account is the simple way in which to enforce context. So an Undo could not impact a hidden account in an unexpected way. Since accounting transactions affect at least two accounts, grouping by account was more of an interface concession. On 3/23/07, Derek Atkins [EMAIL PROTECTED] wrote: I'm not convinced that the Undo feature belongs to an account. There are other (non-account-based) operations that should be undoable, such as changes to the PriceDB, direct Transfer Dialog entries, or even changes made via File - Import. I think the Undo log should be part of the Book (or maybe Session), and there needs to be a way to group operations together into the atomic undo operations. The rest of your statement I agree with, that Undo should check that the state is correct before it allows the undo.. Same for Redo. Thanks, -derek akintayo holder
reference to $LIBGNOMEPRINTUI_URL still kicking around in dist.sh
Hi! /packaging/win32/custom.sh still has a reference to $LIBGNOMEPRINTUI_URL on line 113. libgnomeprintui was removed in r15750. Could we have this line removed from custom.sh? Thanks, Nathan _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Got Mole problems? Call Avogadro at 6.02 x 10^23. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: unofficial windows builds
Hello! Well, I've been building gnucash for about 3 months now and am fairly confident that I've got at least that part down pat. Has anyone stepped up continue the builds for sourceforge? If not, I'd be willing to take this on - Just let me know what to do to get the files up there. I can provide a build every week or so. Thanks, Nathan On 2/7/07, Christian Stimming [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Atkins schrieb: I'm trying to get into creating unofficial gnucash builds for windows (hopefully on a regular basis). Anyways, I thought I'd post the location where I am posting them, in case anyone is interested. http://www.ece.uwaterloo.ca/~ndpbucha/gnucash_builds/ Thanks for posting this! I assume this is an unmodified build of what the install.sh/dist.sh scripts will give you? I.e. you didn't disable any of the (potentially optional) parts? What's wrong with the installers at the GnuCash sourceforge project? As those at sourceforge have always been built by me, and as I won't be able to continue to do so after my workplace change in March, I would happily pass this job over to someone else. Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRcmTz2XAi+BfhivFAQLwpQQAgVed8kEVUBG8qaBnx7ViMUiQId9xp9QM NrdGPaLbJSYevJMMC112d+5fjYcxjFATvs1prsuUneayuV43XIEk5nGgWg40akVs 6TwOLOwxdrSMW3T/y9wivnKvlDayChnKHab4Z0pYOOBm7ephK5Imd53T173/ZCn7 OOljU1GdjKk= =P9d6 -END PGP SIGNATURE- -- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Got Mole problems? Call Avogadro at 6.02 x 10^23. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Inquiry]GNUCash SoC - Implementing Undo
On Tue, 27 Mar 2007, akintayo holder wrote: In the scenario given, It would not be possible to undo from account B as the state of the transaction would've been modified elsewhere. I think it is the lesser of all evils, as a global list may involved undoing a transaction that isn't visible or switching to a different account view. If I were to Undo (3) I would need to show Account C or D by jumping to them, or I could just undo the change quietly. Both seem less than friendly to me. A transaction based approach would cause issues with deletes, and bobbled operations where you cannot find the transaction you just modified usually because you don't know which one it is. I think you are thinking too much like an editor. Undo transactions are recorded in the log (in order to make multi user gnucash work). When you undo a transaction it's a visible and recorded change, not just a simple 'change the entry directly'. I suggest you create a dialog which shows the before and after view. It would have two panes: on top a list of all the transactions affected as they exist now, and on bottom what they will look like after. For things like undo an import, the top pane will have a long list of transactions, and the bottom one will be empty. Or perhaps, since you never delete/add transactions and modify them simultaneously (I think?), have three views: a changed, an added, and a deleted, transaction undo screen. Personally, I would like to be able to browse back and forth through the undos, and I think this will work well: on the left a list of possible undo's, on the right the screen I mentioned above showing what the undo changes. Let the user cherry pick which transaction to undo - it doesn't have to be in strict reverse order. The usual check, which was designed for multi-user undo would still apply: you can not undo a transaction if it's current state does not match it's old. Transactions like that would still be listed, but marked in some fashion - I guess by showing all three version: current, old, and undo. -Ariel On 3/27/07, Peter Selinger [EMAIL PROTECTED] wrote: akintayo holder wrote: Hi, I agree with your points, except for the single GList. I think Undo needs to be local in context. In other words if I Undo from a given register, it should only undo the operations made from that view even if they do not just impact this view. So it must be possible to associate an undo with a view/account. I don't think the idea of a view-local undo will work. Suppose you have a transaction as follows: Account A: +100 Account B: -100 (1) Then you change it, from the Account B view, to: Account C: +100 Account B: -100 (2) Then you change it, from the Account C view, to: Account C: +100 Account D: -100 (3) Then you change it, from the Account C view, to: Account C: +200 Account D: -200 Now suppose you hit undo in account B. What exactly do you expect to happen? Should edits (1)-(3) be undone at once? Or only edit (1), without undoing (2) and (3)? Or none of them? What if you made some other changes in account C after (2) and (3)? Should they be undone as well? I agree with Derek that operations should be undone in the order in which they were performed, i.e., at the book level, not the account level. Alternatively, if a local undo operation is absolutely necessary, then it should be associated with transactions, not with accounts (i.e., undo the last change in the highlighted transaction). -- Peter I would prefer to maintain list for each account, rather than search a global list for undos associated with the type/view. I do see a problem with this approach, but the headache due to multiple lists seems equivalent to the managing a global list. In the global case you would need to be aware of the view/account and maintain positions in the list for each of these, and similar complexity when updating the lists etc. With Import I would assign it to the containing Account Hierarchy. I would be tempted to do so with most dialogs like Price Editor and Security Editor. Reports would be treated to its own GList, as if it were an account. Akintayo On 3/25/07, Derek Atkins [EMAIL PROTECTED] wrote: Um, but which account do you associate it with? When you Undo don't you want to undo from the UI, not on a per-account basis? And what about something like a QIF Import, which really should be an atomic do/undo object? Where would you store that info? Keep in mind that Undo does NOT need to be persistent. As soon as you quit the application it's perfectly reasonable to lose your ability to undo. Think about the emacs undo operations as a decent model. Or Open Office. Personally I STILL think it's better to just have a GList in the session and base your Undo list on that. I think putting it into the account would just cause much more confusion and probably not solve all the problems. Keep in mind that
Re: [Inquiry]GNUCash SoC - Implementing Undo
On 3/27/07, akintayo holder [EMAIL PROTECTED] wrote: In the scenario given, It would not be possible to undo from account B as the state of the transaction would've been modified elsewhere. Modified elsewhere, yes, but it's still the same user. I don't see why this should be restricted to an account view, other than you indicate that it may be simpler to implement. How much more difficult do you estimate a global list would be? I think it is the lesser of all evils, as a global list may involved undoing a transaction that isn't visible or switching to a different account view. If I were to Undo (3) I would need to show Account C or D by jumping to them, or I could just undo the change quietly. Both seem less than friendly to me. How so? I believe Word/OOWriter/most text editors jump to the location of the undo already. A transaction based approach would cause issues with deletes, and bobbled operations where you cannot find the transaction you just modified usually because you don't know which one it is. On 3/27/07, Peter Selinger [EMAIL PROTECTED] wrote: akintayo holder wrote: Hi, I agree with your points, except for the single GList. I think Undo needs to be local in context. In other words if I Undo from a given register, it should only undo the operations made from that view even if they do not just impact this view. So it must be possible to associate an undo with a view/account. I don't think the idea of a view-local undo will work. Suppose you have a transaction as follows: Account A: +100 Account B: -100 (1) Then you change it, from the Account B view, to: Account C: +100 Account B: -100 (2) Then you change it, from the Account C view, to: Account C: +100 Account D: -100 (3) Then you change it, from the Account C view, to: Account C: +200 Account D: -200 Now suppose you hit undo in account B. What exactly do you expect to happen? Should edits (1)-(3) be undone at once? Or only edit (1), without undoing (2) and (3)? Or none of them? What if you made some other changes in account C after (2) and (3)? Should they be undone as well? I agree with Derek that operations should be undone in the order in which they were performed, i.e., at the book level, not the account level. Alternatively, if a local undo operation is absolutely necessary, then it should be associated with transactions, not with accounts (i.e., undo the last change in the highlighted transaction). -- Peter I would prefer to maintain list for each account, rather than search a global list for undos associated with the type/view. I do see a problem with this approach, but the headache due to multiple lists seems equivalent to the managing a global list. In the global case you would need to be aware of the view/account and maintain positions in the list for each of these, and similar complexity when updating the lists etc. With Import I would assign it to the containing Account Hierarchy. I would be tempted to do so with most dialogs like Price Editor and Security Editor. Reports would be treated to its own GList, as if it were an account. Akintayo On 3/25/07, Derek Atkins [EMAIL PROTECTED] wrote: Um, but which account do you associate it with? When you Undo don't you want to undo from the UI, not on a per-account basis? And what about something like a QIF Import, which really should be an atomic do/undo object? Where would you store that info? Keep in mind that Undo does NOT need to be persistent. As soon as you quit the application it's perfectly reasonable to lose your ability to undo. Think about the emacs undo operations as a decent model. Or Open Office. Personally I STILL think it's better to just have a GList in the session and base your Undo list on that. I think putting it into the account would just cause much more confusion and probably not solve all the problems. Keep in mind that users want to undo changes that aren't necessarily transaction input! You might want to undo, e.g., a PriceDB entry, or a new Customer, or an Invoice entry, or... Lots of things that don't touch Accounts. Just something to think about. Getting the architecture right is important to success. -derek akintayo holder [EMAIL PROTECTED] writes: The reason I like Undo being associated with an account is the simple way in which to enforce context. So an Undo could not impact a hidden account in an unexpected way. Since accounting transactions affect at least two accounts, grouping by account was more of an interface concession. On 3/23/07, Derek Atkins [EMAIL PROTECTED] wrote: I'm not convinced that the Undo feature belongs to an account. There are other
Re: [Inquiry]GNUCash SoC - Implementing Undo
Yes, that first one is a problem and one that I have not personally experienced - so I am guessing a bit. But if you create the entry in one view then commit [guessing about this part] and move it to another view. Then I would place the Undo entry in the first view's list, as you haven't updated it from the new view as yet. So if you were to then Undo the transaction would return to the context in which it was being edited. But all the changes would've been undone, and it would be as it were before you started the updating. I think displaying the operation being Undone is fine, but I am not fond of multiple Undo menu options. Undoing import was one of the first things Derek mentioned, I think the problems are ensuring atomicity and multiuser access. I don't expect it to be easy to do, especially since each transaction's state must be checked and updated in an atomic operation. Akintayo On 3/27/07, Beth Leonard [EMAIL PROTECTED] wrote: On Tue, Mar 27, 2007 at 02:07:03PM -0300, Peter Selinger wrote: I agree with Derek that operations should be undone in the order in which they were performed, i.e., at the book level, not the account level. I'll add my me too here. With splits it gets particularly complicated. One of the things I most want to undo in GnuCash happens when I'm editing a complicated split and as part of that process I change (accidently or not) the account that I'm using to view the split at the time. The whole thing suddenly dissappears and I'm left with a what just happened? feeling -- I know something's wrong but it takes me a little while to figure out that my whole transaction just moved to another account view. I think undo has to work at a global level. Naming the action that is going to be undone in the menu item is a good start -- i.e. Undo edit transaction Undo delete transaction Undo import prices Undo import QIF Undo change report options Undo change account name Undo delete account etc. This way the user has some idea of what is going to be undone when they click that item. The second most likely thing I want to undo is importing a QIF or QXF file. I've taken to using save/restore just in case the file I import isn't the file I thought it was. --Beth Beth Leonard http://www.LeonardFamilyVideos.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Inquiry]GNUCash SoC - Implementing Undo
On Tue, 27 Mar 2007, Nathan Buchanan wrote: On 3/27/07, Ariel [EMAIL PROTECTED] wrote: Let the user cherry pick which transaction to undo - it doesn't have to be in strict reverse order. This sounds a bit complicated for the average user, if we do decide to let the user cherry pick, we need to have a very clear UI/warning about undoing transactions out of order. The fact is that most people think of things in a specific order, and whenever we allow going backward (undoing) in a different order, we need to be crystal clear about it. When I enter transactions, usually there is no order, one transaction has nothing to do with another. It's not always like that obviously, but I think changes to transactions are the primary 'atom' here. Not changes to gnucash as a whole, so there is no reason not to do this. By making undo keep track of changed transactions, rather then total program state I think it makes the code easier - undo piggy backs on top of the transaction log. Each time something is written to the log, it's also written to undo - in fact a large part of undo is already written: the log already records a before and after, all you need to do is put in a gui to see each entry in the log and you are all set. There was debate earlier on where to 'attach' the undo, to the register view, to an account, etc - I say just use the transaction log, you know it works and it's already written. Also, how would redo work (when it gets implemented)? Say a user makes change 1, 2, 3 and 4. ,Then the user undoes change 1 then change 3. Does redo redo change 3 then change 1? This may be difficult for the user to keep straight. Yes, remember: when you undo something it goes in the log exactly as if you had typed it yourself. So when you undo something, then the 'undo' in and of itself goes in the undo list. So redo is just undo twice. -Ariel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
