[GNC-dev] Dev's features of choice?

[Christopher Lam]

LUndo/redo could be implemented as a journalling type table, where each new
row describes the change in state. But then you're recreating sqlite, and
would require deep architectural changes. Probably not possible in this
lifetime.

On Mon, 27 Jul 2020, 12:33 pm jean laroche, <ripngo at gmail.com> wrote:

> OK thanks for all the opinions. As usual with collaborative projects,
> it's a bit messy, we don't all have the very same optics, which I think
> is probably a good thing!
>
> I would agree with John that undo/redo is very challenging if it's
> applicable to all actions with "infinite" undo/redo. I've thought about
> it a bit, and there's nothing that seems easy to me that would give a
> fully functional undo/redo. Even if you saved the state of the database
> for every action (granularity to be defined!) restoring it, and going
> back exactly where you were would not be a simple matter...
>
> In any case, thanks for chiming in.
> Jean
>
>
> On 7/26/2020 8:52 PM, John Ralls wrote:
> > There's already a cancel button for the first part.
> >
> > There's no undelete, but it wouldn't be to hard to implement: Just make
> a second set of QofContainers to hold deleted objects until the end of the
> session and provide a dialog to list them and allow them to be returned to
> the primary container.
> >
> > The normal undo-redo stacks common in other programs would be a bit more
> complex but the technique is well known, it's just really tedious to
> implement. Where the problem gets quite a bit more interesting (read:
> complex and difficult with decisions about depth and granularity) is when
> the undo stack reaches back into already committed transactions. Do you
> save a copies of each object for every keystroke or treat an edited
> transaction like a deleted one? How do you handle an import of many
> transactions, some new and some matched-and-updated? That's just the
> beginning, GnuCash is complicated. It could easily turn into several years
> work for a skilled software engineer; definitely not a job for a hacker.
> >
> > Regards,
> > John Ralls
> >
> >
> >> On Jul 26, 2020, at 7:59 PM, Bruce Irving via gnucash-devel <
> gnucash-devel at gnucash.org> wrote:
> >>
> >> While I'm not a professional, there is a point about undo that I would
> like to see - sooner than later:  I start to edit a transaction but, before
> I commit it (press enter or move to another transaction). I realize that I
> didn't want to do that and would like to cancel my edit, restoring the
> transaction to what it was.
> >>
> >> And, I have accidentally deleted a transaction on more than one
> occasion.  It would be great if I could restore that transaction rather
> than completely re-enter it, hoping I remembered what was in it - I don't!
> >> Bruce
> >> Preach the Gospel wherever you go.
> >> If necessary, use words.
> >>
> >> 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.
> >>
> >> So I see at least a better auditing system as a requirement before your
> >> suggestions. The current logging would need a review. It should cover
> >> all changes, not only simple transactions. ISTR business actions and
> >> structural changes are not recorded.
> >>
> >>> I'm curious specifically about devs because they typically have a
> >>> different perspective on the project than users have.
> >>> Jean
> >> About the future I almost agree with Johns suggestions.
> >>
> >> Regards
> >> Frank
> >>
> >> _______________________________________________
> >> gnucash-devel mailing list
> >> gnucash-devel at gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>