Beyond 2.8 - some design thoughts

Wm wm_o_o_o at yahoo.co.uk
Wed Dec 27 06:51:32 EST 2017


On 24/12/2017 16:34, Geert Janssens wrote:

[snips below, hopefully context maintained]

> 1. Use of namespaces.

> For 2.8 I have been working on converting parts of the CSV importer to C++.
> And considering the class structure that is slowly forming there (still in
> flux as conversion of additional importers reveals design limitations that
> shouldn't be there) I am even tempted to use nested namespaces there (not
> nested classes, mind you) like

> On the other hand I don't have much experience with namespaces yet (other than
> using st:: and boost:: which have nested namespaces as well) so I don't know
> the pro's and con's of it. So I'm interested in opinions about this.

I'm not sure what most people consider CSV accounting data is useful to 
begin with, although I also know it can't be ignored entirely.

The ever-improvement of the csv import is a project that will always 
fail, it happens every time someone exports a csv file from their 
accounting program / spreadsheet and the gnc import doesn't say "hooray, 
I love your format, we bow to your format".  I suggest a presumed import 
format of ledger-cli type data and levering the work of shared open 
source accounting data.  Writing a script to get from a csv into 
ledger-cli is transparent, portable and useful to a broad community.

It also means only one significant import / transfer format for gnc and 
related software to concentrate on <-- very good thing.


> 2. Versioning.

> The migration to gtk2 has been a long
> time ago and the software world has evolved since then. Release cycles in
> general have shortened. Incremental changes are usually preferred over big
> bang changes. So I think our numbering scheme is in for a modernization.

gnc's versioning does seem dated although I expect people that read the 
dev list may be used to them by now.

As someone less involved in gnc coding but with a lot of interest in 
data I'd have thought the next non-backward compatible format change 
would be the next gigantic.

-- 
Wm



More information about the gnucash-devel mailing list