More Cutecash (was: Is there anything I should know to replace GnomeDruid with GtkAssistant?)

[Christian Stimming]

Am Wednesday 30 June 2010 schrieb Phil Longstaff:
> when I look at that page, I see "There is currently no text in this page.

Fixed. But the announcement of http://wiki.gnucash.org/wiki/Cutecash (I wrote 
it without the camel-case in my previous messages) was already done earlier.

> Have you thought through a series of milestones 0.1, 0.2, ... to port the
> current code.

No, not yet; currently this is only targeted towards more developers who like 
to explore how super-fast and developer-friendly a finance GUI can be as well.

> We need replacements for the register and html engine (is
> there one built into Qt?).

Register: I've already finished the single-line register view, just follow the 
wiki instructions. There is a good model/view infrastructure available in Qt 
so that was easy (and, again, it is super-fast compared to gnucash).

HTML: Still undecided. Qt ships with webkit which would do as HTML viewer, but 
this doesn't solve the report generation question. Discussion on the wiki 
page.

> We need to pull the business code/UI apart -
> by "business", I mean object manipulation code rather than code for
> invoices/employees/customers.  I know you've talked about merging a lot of
> the current modules into one big module.  On first glance, I'd like to
> see: - engine - current objects (including business objects)/qof
> - back-ends - different ways for the engine to load/store data somewhere

Yes, the "engine" and "back-ends" are beingre-used from the gnucash C code by 
compiling them all in static libraries (defined in the cmake infrastructure, 
so they don't interfere with the gnucash Makefile.am) and linking them into 
the resulting C++ executable.

> - "business code" - includes reports, possibly configuration/preferences,
> register core (sorting, editing, blank transaction), ...
> - UI - interface between business code and the GUI package
> (Qt, WxWindows, ...)

The UI of cutecash will be Qt, see the discussion on the wiki page. However, 
I'm not yet convinced another separate "business code" layer really improves 
the resulting product here. Clearly, gnucash does not have any useful 
abstraction on that layer, apart from what's already in engine and app-utils. 
After all the years in gnucash I tend to say there is too little benefit in 
creating such an extra abstraction so it's very unlikely to "get it right", 
which in turn means it will be useless anyway. Instead, I want to put a strong 
focus on the end user experience, which means it's fine for me if we get along 
without such an extra abstraction layer.

> I see the engine being useful on its own (and wrapped for use by python,
> scheme, java, ...) to allow other apps to access the data.  I suppose
> backends could be part of the engine.

Yes, that's my view as well.

Best Regards,

Christian