r19673 - gnucash/trunk/src/backend/sql - Bug 632166: Notify user when something goes wrong with a transaction save.

[Geert Janssens]

On Tuesday 19 October 2010, John Ralls wrote:
> On Oct 19, 2010, at 2:22 AM, Geert Janssens wrote:
> > On Monday 18 October 2010, John Ralls wrote:
> >> Author: jralls
> >> Date: 2010-10-18 17:56:05 -0400 (Mon, 18 Oct 2010)
> >> New Revision: 19673
> >> Trac: http://svn.gnucash.org/trac/changeset/19673
> >>
> >> Modified:
> >>   gnucash/trunk/src/backend/sql/Makefile.am
> >>   gnucash/trunk/src/backend/sql/gnc-transaction-sql.c
> >> Log:
> >> Bug 632166: Notify user when something goes wrong with a transaction
> >> save.
> >>
> >> _______________________________________________
> >> gnucash-patches mailing list
> >> gnucash-patches at gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-patches
> >
> > John,
> >
> > This change is definitely an improvement to the silent data loss issue we
> > had.
> >
> > I see that your commit now introduces a gtk dependency in the sql backend
> > while it was strictly gui independent before. I have postponed fixing bug
> > 630770 [1] because I wanted to avoid adding gui code to the backend. My
> > main reason for keeping the databackends free of gui code is that other
> > programs may use this code, programs that aren't necessarily using gtk.
> > The first example is CuteCash, a second example are the python bindings.
> >
> > I'm not sure what the best course of action is here. Silent data loss is
> > a severe flaw, so perhaps it's better to have the introduction of a gtk
> > dependency now so we can continue, and clean it up properly in the 2.5
> > development cycle. Or perhaps the majority of the devs doesn't consider
> > this an issue in which case nothing has to be done.
> >
> > Cleaning it up now would probably be challenging or too intrusive. When I
> > was investigating a way to fix bug 630770 I came to the conclusion that
> > backend errors are not reported back all the way into the GUI code. There
> > were several in between layers that had to be altered for that.
> >
> > If the choice is to clean it up later, we best keep a bug report open for
> > this.
> >
> > What do others think of this ?
> 
> Geert,
> 
> You raise a very valid point. Mixing the gui into the  isn't a good
>  long-term approach, especially if we're going to dump Gtk anyway. On the
>  other hand, the backend already uses gopbject pretty extensively and that
>  is all going to have to be redone in C++ (or come other OO language, but
>  C++ will be easiest) if we're going to get away from Gtk.
> 
I'm not sure if all has to be redone in C++ or another OO language. At least 
not necessarily in the same refactoring phase. My understanding was that even 
Cutecash would initially only focus on an enhanced gui on top of the current 
qof/gobject based engine.

> We need a global error handling class (it can be grafted onto qoflog) with
>  a single-point dependency to a message box facility in gnome-utils.
> 
Agreed.

> We also need to get 2.4 out, and we need to flag back end errors. I think
>  that if we're going to ship 2.4 anytime soon, we're going to have to
>  accept the gtk dependencies in the back end for this release. 
>  Accordingly, I've created [1] to track this, and set it's target to
>  "future".
> 
I tend to agree with this. Thanks for the bugreport also. That will ensure we 
won't forget this needs some cleaning up later.

Geert

> Regards,
> John Ralls
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=632558
>