Win32 Port Efforts (eKA$H fork)

[jarney1 at cox.net]

---- Christian Stimming <stimming at tuhh.de> wrote: 
> Thanks for this information and the link to the download page (although
> the download rate seems to be rather slow, 56 KB/sec?). I'm sorry to
> hear about your effort only with this 4-weeks-moderation delay. Surely
> the gnucash-devel list is the better place to discuss this contribution.

Thanks.   I'll discuss on gnucash-devel in future.  Our website (and business) are being bootstrapped right now.  We have 2 employees (myself included)  The download rate on our website reflects the income stream (none) we have to support the effort.  With luck, our income and download rate will increase in kind.

> Thanks for the feedback about the wiki page. As you can guess yourself,
> it's a bit of a pity that you have been working on the 2.0.0 code for
> your fork "eKA$H", whereas we have been using SVN-trunk for the other
> porting effort. This means many potential upstream patches probably
> duplicate changes that we already have.

Yes, this is a pitty, but what's done is done.  I'm happy enough to have done it for my own purposes.
 
> > Many win32 port efforts consist of loosely coupled sets of packages,
> > each having to be installed manually and conflicts abound. The approach
> > that eKOS financial has taken is to model the win32 port effort more
> > closely after GNU/Linux distributions and what results is a GNU/Win32
> > distribution which we are terming the eKOSystem.
> 
> Actually, such an approach would be very useful for the "native" GnuCash
> win32 distribution as well. Do you think it could also be used by the
> original gnucash developer group, i.e. without the kind of rebranding
> that you added in your forked source code?

Yes.  It is an open-source effort and not much of it is branded to begin with.  Everything on our website is GPL and outside the branding can be used for any purpose whatever.  I hope that others can use this effort to their own benefit.
 
> * All in all I can see approx. 250 files that have been modified by you;
> I'll attach the unified diff between gnucash-2.0.0 and your modified
> version for the other developers to see, in the three sequential batches
> that you implemented (step 1-3).

Wow.  Thanks.  I had intended to do that but time constraints prevented me.  Once again, the beauty of an open-source effort!  Perhaps I'll get a moment to try again starting with the SVN source and apply some of my diffs more carefully and deliberately.

> Some discussion, starting from your latest changes (gnc-win32-step3):
> 
> * In src/app-utils/gnc-ui-utils.c you did two changes, adding
> gnc_lconv_set_utf8(&lc.positive_sign, ""); and
> - -  while (fraction != 1)
> +  while (fraction > 1)
> Any reasons for these two?
> 
> gnc-win32-step2.diff:
> 
> * Obviously you worked around the fact that win32 doesn't have "%lld"
> for scanf by implementing your own code for this format. However, I
> discovered win32 has "%I64d" (SVN r14806). Is there any problem with
> that format?

I was not aware of it.  I'm the worst kind of hacker.  Your implementation is probably more correct.
 
> * You did some changes in the QIF import, but those don't seem to change
> the real code, do they? Did you observe any problems with QIF importing
> on windows?

Here's the scoop.  The QIF import kept crashing for me.  For a long time, I went down the road of trying to "printf" my way through the bug.  The bug kept "going away" when I added debug code to it.  I finally concluded that the bug was in the fact that part of my source chain was linked against the "gtk+" that comes with mingw natively and another part of my source chain was linked against the "gtk+" that I built as a part of our unified package.  Once I recompiled everything against a coherent set of sources, the symptom went away.  Any changes to the QIF import are therefore incidental and can be safely ignored.
 
> * You replaced the type names GUID by GNC_GUID and CURRENCY by
> GNC_CURRENCY, IGNORE by GNC_IGNORE and others. Any reasons for this,
> especially the latter two? I vaguely recall GUID being defined in some
> winapi header file, but in SVN-trunk apparently there's no longer a
> problem with this. Unfortunately this makes the diff quite hard to read.
> You don't happen to have a source tree with only these two namechanges,
> do you? :-)

I do not.  The win32 API header files do define GUID, CURRENCY, and IGNORE.  The GNC_ versions of these are intended simply to remove this colission.
 
> * In lib/libqof/qof/qofbackend.c you added some extra code that is
> calling some libtool functions. Should this avoid double-initialization?
> When would this be a problem?

The use of lt_ modules instead of g_module modules is probably not required.  See earlier discussion on linking to two different glib/gtk instances.
 
> * You added an extra data field to the Account data type, "asset class",
> along with appropriate reading/writing code in the xml backend and an
> extra asset-class.scm scheme report. What do you intend to use this data
> field for? Also, this additional data field probably makes the data
> files GnuCash and your fork "eKA$H" mutually incompatible (because the
> gnucash parser will choke on the unknown XML element)?

The "asset class" field was intended for tracking securities for balancing an investment portfolio.  When you do this, an "Asset class" refers to a classification of securities.  The dominant wisdom in investing is that you should balance risk across different asset classifications (i.e. large cap, mid cap, small cap, bond).  The XML document needs to track this and the corresponding report tells you what percentage of holdings are in these categories.  From time to time, you should balance your holdings so that the balance of each category is maintained.  The good news is that so far, I don't think more than 5 people are using this version, so if another solution to tracking asset categories is found, switching over to it should not be a problem.

> * Did you find a solution for lauching a gzip child process for writing
> or reading compressed files? In your latest source it doesn't seem so,
> as the code will still write/read uncompressed files only.

I did not.  I have the same problem in several other applications (dia, inkscape, etc)
 
> Feel free to continue to do so - that's the wonders of open source.
> However, the potential data file incompatibility due to the "asset
> class" data field would really bug us. Do you think you can implement
> this with sufficient forward- and backward compatibility?

Given that not many people are using it yet, I would like to work out a way to implement this functionality in the upstream if possible.  It need not be compatible with what I have.  Would it be a reasonable comprimise to add some kind of "misc" field(s) in the XML format for purposes similar to this?  In that way, we could achieve compatibility and flexibility in one fell swoop.

> Good to hear. We also don't know more about this except for what is
> already written on the wiki page. Thank you for your feedback and good
> luck with your own business model and software package.

I may need the luck.  Currently, the "business model" consists of hanging around street corners with CDs saying "hey buddy, wanna buy some source?"

Cheers,

-Jon Arney