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