Because while GnuCash lacks the controls and some modules (c.f. the recent request for cost accounting; we also get frequent questions about whether we support payroll, inventory control, and POS for retail) required by many businesses, it is double-entry and designed for users who want a formal accounting app. If you're more interested in a Quicken work-alike try KMyMoney.
That said I don't agree with Frank that transactions should be immutable, though we have a preference that can get you pretty close to that if you want. The real difficulty with bulk edit is GnuCash's edit-commit structure that as you recently discovered in imports makes bulk modification rather slow. Changing it without breaking a lot of other things would be difficult. There are also accounting controls issues: Remember that you punted on enforcing same-commodity on bulk moves of transactions in sub-accounts when deleting the parent account because of the spiraling complexity. Undo/Redo is maybe another matter. The simplest form would keep a stack of changes to the Gtk controls while some element--a transaction in the register, a business object, or a dialog box--is between being open and committed. Implementing that would be mostly tedious. Being able to undo already committed changes would require a good deal more care and perhaps some changes to the edit-commit behavior in the backend. Regards, John Ralls > On Jul 26, 2020, at 4:50 PM, jean laroche <rip...@gmail.com> wrote: > > But why??? > > > On 7/26/2020 3:38 PM, D. wrote: >> Jean, >> >> I think you raise a valid point. There does seem to be a tendency in the >> community to assume that a certain amount of inconvenience is to be >> expected. The reasons vary, but the underlying tendency remains. >> >> David T. >> >> >> -------- Original Message -------- >> From: jean laroche <rip...@gmail.com> >> Sent: Sun Jul 26 17:49:47 EDT 2020 >> To: "Frank H. Ellenberger" <frank.h.ellenber...@gmail.com> >> Cc: GnuCash Developer <gnucash-devel@gnucash.org> >> Subject: Re: [GNC-dev] Dev's features of choice? >> >> >> >> On 7/26/2020 1:54 PM, Frank H. Ellenberger wrote: >>> Hi Jean, >>> >>> Am 26.07.20 um 19:57 schrieb jean laroche: >>>> I'm curious about something: >>>> If you're a GC dev, contributing code to the project, what's the >>>> feature(s) you'd like to see added to GC? >>>> I'm only contributing a bit, but I'll offer my 3 top wishes: >>>> - Undo/(redo) >>>> - Multi-transaction (bulk) editing >>>> - Multi-account (bulk) editing >>> All three are violations of strict accounting rules. We often talk about >>> "In the times of ink and paper", not graphite (pencils). Some >>> governments require the immutabiity of once written records. >> I see a disconnect here. Some of us (John in particular) insist that GC >> is not a system for professionals, only for personal finance. >> Yet, I always hear about accounting rules, and the way it should be done >> by the book. If GC is really for the personal user, I don't understand >> how we can survive without undo/redo, and multi-select. *every* piece of >> software out there has these types of features, and they're invaluable. >> J. >> _______________________________________________ >> 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel