r19673 - gnucash/trunk/src/backend/sql - Bug 632166: Notify user when something goes wrong with a transaction save.
jralls at ceridwen.us
Tue Oct 19 10:03:53 EDT 2010
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
>> Bug 632166: Notify user when something goes wrong with a transaction save.
>> gnucash-patches mailing list
>> gnucash-patches at gnucash.org
> 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  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
> What do others think of this ?
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.
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.
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  to track this, and set it's target to "future".
More information about the gnucash-devel