Where to discuss the development of gnucash (Re: KMyMoney vs Gnucash)

[Geert Janssens]

On Friday 22 August 2014 18:57:46 Michael Hendry wrote:
> On 22 Aug 2014, at 17:06, Geert Janssens <janssens-geert at telenet.be> wrote:
> > Michael,
> > 
> > You're still hijacking the thread. A good hint for that should be
> > the
> > title: it's called "KMyMoney vs GnuCash", not "how should an
> > accounting program be developed".
> > 
> > But since the original thread is now dead anyway, I will continue on
> > this one but change the subject so people can more easily decide if
> > they want to follow this twist in the subject or not. I didn't do
> > so before because I presumed the discussion would end. I was wrong.
> > 
> > And I'll repeat my original stance: the *user* mailing list is *not*
> > the place to discuss *how* gnucash should be designed. Here's the
> > description of the mailing list [1]:
> <Big Snip>
> 
> Phew! It’s getting a bit hot around here!
> 
Thanks for helping me cool down. I was not feeling happy after my last mail yesterday. So I 
apologize for stretching it too far.

> As a user of GnuCash since 2010, using it for my own personal finances
> - no invoicing, no inventory, no uploading of bank statements or
> stock prices - I get all I need from the program itself, and have had
> a lot of help from the users list over the years.
> 
> I think there _is_ a place for discussing the overall direction of
> development in the users list, so that users like me can understand
> why development hasn’t taken place in a given direction - most of us
> would be completely lost in the development list.
> 
Hmm, yes there is truth in that as well. It may be too technical on the development list.

> Granted, the user list is not the place for discussing the
> nitty-gritty details, but it’s helpful to know the constraints that
> govern what can reasonably be included in a volunteer-developed
> program, in general terms.
> 
That's a good way to summarize it and that's a very reasonable position on the level of detail to 
discuss.

> I’m very much a fan of the Unix-etc idea of having simple tools which
> once developed do the same job consistently over the years, and can
> be chained together with others to do more sophisticated work. I’m
> getting out of my depth here, but I believe that the “plugins” which
> are used as add-ins to a lot of software provide a model for extras
> that might be added to GnuCash to deal with inventory, quotations and
> bizarre tax regimes. The feasibility and desirability of this would
> properly be discussed on the devel list.
> 
So far I deliberately never commented on this part of the conversation, but it keeps coming up. 
So here's my thoughts on this as well:

I agree plugins are useful to some extent, particularly for localized stuff like different tax 
regimes. But there are limits to what can be achieved with a plugin and from my perspective as 
a developer the current GnuCash code has stretched it way to far.

I'll give an example: the business features were a plugin until 2.4 came out. That means that 
the core gnucash code did not know anything at all of anything related to the business part.

As a result integration was very limited. For example there was no way to implement the 
"Assign as payment" context menu that is currently in the account registers (this is a helpful 
command to mark any random transaction as a payment for a bill or an invoice). The register 
code couldn't know about the business code because it was in a plugin and hence could not 
interface with it.

The fact that the business features were in a plugin and that the import functions are still 
written as plugins are also the reason you can't assign a transaction to an invoice/bill while 
importing your bank statements. The two plugins couldn't communicate because they couldn't 
even assume both were loaded. I know this has been asked for several times.

And lastly if a plugin generates its own data like the business code does, how should this data 
be treated when it is opened in a version of gnucash that doesn't have the plugin ? I'm not 
expecting an answer here, just illustrating the complications to take into account :)

Those are just a few examples from the top of my head. GnuCash code is currently filled with 
such kind of restrictions due to extreme "pluginification" (an heritage from its guile roots). 
Dealing with this makes the program orders of magnitudes more complicated than is necessary.

So yes, plugins can be useful, but with restrictions.

Geert