Confusion about use of G2

[Neil Williams]

On Sunday 02 October 2005 7:46 pm, Chris Shoemaker wrote:
> > |         Now I understand any such policy is merely an ideal whose
> > | actual application must also consider many practicalities.
> >
> > One of which is spinning out QOF.
>
> Care to explain that?  I was more thinking about practicalities such
> as developer time and efficiency.

1. Removing scheme/guile from the engine code - an inherent task within 
spinning out QOF, two sides of the same coin.

2. Not to put too fine a point on it, my developer time copying QOF files into 
GnuCash each time it needs an update! Gnucash is benefitting from wider use 
of QOF and will benefit much, much more as cashutil develops. I know that 
probably doesn't matter to you but it does to me.

3. In terms of user experience and expectation in G2, QSF exports and QOF 
merge will provide solutions to real user problems relating to data import, 
export, mining and customised report generation. The GUI code to get the best 
out of QSF is not all in place but there is sufficient - particularly with 
the business features - to make it very useful. Adding similar commands to 
export accounts and transactions between specified dates into QSF is a small 
task - it depends on how other things pan out.

If you limit it to an empty feature-parity then this last fix for the error 
logging and finishing the fix to the backend load method are the only 
remaining QOF tasks. The rest of the code is already in place and has been 
for some weeks.

> > I get the same with all the GOffice code and it's dependencies. Then OSX
> > has horrible problems with the frequent use of -module in the makefiles.
>
> You get massive patch breaking due to code churn?!?  What code has
> been churning under you? Surely not GOG.

The goffice code in the gnucash tree hasn't necessarily changed, but the 
dependencies of that code HAS changed, that's why I have several patches for 
files under lib/goffice to allow it to compile. I'll be looking at using 
external GOffice libraries soon - should have done it earlier but had to get 
QOF ready for pre-release.

> > I wish you'd said something when I started talking about trace changes
> > on this list. Are these changes compatible with using trace via the
> > external QOF library?
>
> Some are.  Some aren't.

So what are the benefits of your trace changes? What do they cover?

> There might be a logical leap here.
>
> 1) QOF needs release imminently.  [ Let's take this as a given. ]
>
> 2) GC needs to use QOF as external library.
>     [ I'm not exactly sure how strong a need I would admit, but let's
> assume this is completely true. ]
>
> 3) Therefore, GC needs, in the next G2 release, all these
> architectural changes to support the new release of QOF.
>
> I don't see 3) following from 1) and 2), but feel free to make the
> case.

1. GC needs the backend to be fixed. There is a working fix out-of-tree but it 
needs to be fitted into GC.
2. I anticipate that remaining issues should be small and therefore it is 
worthwhile seeing if G2 can work with an external QOF once the backend is 
fixed. I see no point in releasing G2 with an internal QOF library that is 
maybe 99% identical to 0.6.0. I really do feel that once the backend is 
fixed, the remaining work is that small. This last patch achieved a massive 
amount of progress on separating QOF from gnucash. It could (should) have 
been done a long time ago.

> Don't assume that everyone knows what you know about the wonderful
> benefits of QOF.

My motivation at the moment is simply to avoid duplicate code. Whenever 
possible, G2 should be allowed to use an external QOF library that will be 
available before G2 and which contains virtually identical code.

> Please explain why G2 can't be released, with 
> feature parity with "G1", without architectural improvements.

The only remaining problem is that in the backend. I expect to be able to fix 
that in the next two weeks (I'm away most of next week). The current gnc- 
code is not working properly.

There are also architectural changes to the makefiles for libraries that use 
-module for G2 to work on Mac OSX. Those warnings that we all see about 
linking executables against ... library not beng portable - those warnings 
bite on OSX and those were not a problem with the 1.8 tree (I think due to 
the version of gcc available for 1.8). They will, however, halt the build of 
any G2 package if not fixed.

A relatively minor change that I need to be able to test and then implement.

> Note 
> that it's not enough to simply explain how great QOF is for GC.  Lots
> of things are great for GC that won't be in the first release of G2.
> Why should all these QOF changes?

1. To make use of the gnome2 architecture at the level of glib.

2. To prevent duplicate code - I will do everything I can to allow G2 to go 
into at least Debian with an external QOF dependency. I have completed the 
vast majority of that work, I only have a few fixes left to implement. After 
that, libqof1 will remain API compatible for some time so gnucash can make 
subsequent releases without problems or synchronisation. It's just that there 
have been so many changes from QOF 0.5 to QOF 0.6, it's all a little fraught 
at the moment.

> > Then there are the changes required to work with cashutil - again these
> > are architectural changes to libraries and makefiles, as well as the
> > abstraction of the GUI logic into a library to be shared with cashutil.
>
> Again, fine, let's assume cashutil is wonderful.  Do we have to make
> architectural changes to G2 to work with cashutil in order to achieve
> feature parity?

No. cashutil is completely separate, it has helped me fix the backend problem 
but it's main contribution won't be visible for a time after QOF 0.6 and G2. 
I could not have started cashutil without the work I've done already for QOF 
and the new pilot-QOF application.

> > I've got a usable undo framework out-of-tree and it will stay there for
> > now. I'll also be implementing the logic abstraction out-of-tree. I
> > can't introduce those to the gnucash tree until gnucash itself is closer
> > to accepting cashutil which in turn requires a completed QOF spinout.
>
> [I'm assuming you're thinking post-G2 release here.]

Yes, principally because cashutil requires large amounts of new or relocated 
code to implement the logic. That code is nowhere near ready.

> So you *do* see 
> a distinction between architectural changes that should wait until
> after G2 is released and those that are necessary now?  Could you
> explain what that distinction is?

1. QOF 0.6.0 is ready and I want to do what I can to allow gnucash to use it 
fully.
2. cashutil is a recent addition and is not ready.
3. Undo is simply too large a feature to add in these circumstances. It is 
still v.new and insufficiently tested.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051002/4bc1ecf3/attachment.bin