Beyond 2.6

John Ralls jralls at
Tue Feb 12 14:17:38 EST 2013

On Feb 12, 2013, at 9:33 AM, Derek Atkins <warlord at> wrote:

> John Ralls <jralls at> writes:
>> On Feb 12, 2013, at 9:06 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>>> Geert Janssens <janssens-geert at> writes:
>>>> Indeed. I mostly meant to suggest our *engine* should be totally
>>>> multi-platform. The gui should be adapted to the target OS and
>>>> form-factor anyway. I wouldn't want to use a gui similar to current
>>>> GnuCash's one on an Android tablet for example. Having the engine
>>>> available on say Android, that could make Ngewi's work a lot easier:
>>>> instead of importing/exporting, he could plainly open a real gnucash
>>>> datafile and work directly on it. That doesn't mean the GnuCash on
>>>> Android tool should support all the features GnuCash on
>>>> Linux/OSX/Windows does, but it would be able to properly load and save
>>>> the file without any data loss.
>>> I think in the long run it would behoove us to try to migrate more of
>>> the "business logic" into a core platform, too.  But I'm not sure
>>> exactly how to do that in a clean way that provides "real-time"
>>> validation of inputs, without it being tied into the GUI.
>> What do you mean by "real-time validation of inputs"?
> I mean, e.g, making sure an Account has a name entry, and that it's
> unique, and that the account type is valid based on the parent..  Those
> kinds of input validation that's currently done in the dialog.

Those checks should be part of the Account constructor, and would throw exceptions. The interface code between the engine and Gtk+ would convert those exceptions into GErrors for the dialog box to handle; C++-based UI frameworks would be able to catch the exceptions directly.

John Ralls

More information about the gnucash-devel mailing list