Future allocated money, aka Envelope Budgeting

[Matt Graham]

Wow! That become contentious quick!!!

The primary issue I’m seeing here is one of philosophy. What is GNUCash for? What is the purpose? What “should” be included and what “shouldn’t” be?
As has been highlighted, when someone loads up software they have a preset notion in their own mind of how it “should” work, and that is usually their own very narrow context (e.g. “That’s not how budgets work!”).

My assumption on purpose: Open source software is created out of need and altruism. People who know how and want help create and maintain the project both because they are interested in software and enjoy the process, but also because they like being altruistic and providing something that others find useful.

Based on that assumption, I have had the attitude “All requests should be considered and prioritised by the devs, but of course they will mainly implement what they find useful and of course they will only give how much time they can afford to”.

The natural flow on from my attitude is that I should indeed throw in what I want/need from my financial tools, but not expect anyone to act on it. If I want it done, I need to donate my time and implement it because it is definitely unreasonable to demand others to do it when it isn’t useful for them. (On that note, I’m keen to help out, but don’t yet have knowledge (and also struggle for time) in all this).

I have lots of specific comments against what people are saying, but all would be unhelpful if my fundamental attitude to the project is wrong.

Thanks and regards,

Matt

From: John Ralls<mailto:jralls at ceridwen.us>
Sent: Saturday, 3 February 2018 3:51 AM
Cc: gnucash-devel<mailto:gnucash-devel at gnucash.org>
Subject: Re: Future allocated money, aka Envelope Budgeting



> On Feb 2, 2018, at 7:25 AM, Wm via gnucash-devel <gnucash-devel at gnucash.org <mailto:gnucash-devel at gnucash.org>> wrote:
>
> There is, IMO, work to be done on on the underlying db structure, have you seen this monster ?
> ===
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2Fimages%2F8%2F86%2FGnucash_erd.png&data=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636531870670279982&sdata=aEzd9p0oY9t1%2Bczj66N5%2Fg3bfwhBmGEq6YCXy2xn%2FEA%3D&reserved=0 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2Fimages%2F8%2F86%2FGnucash_erd.png&data=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636531870670279982&sdata=aEzd9p0oY9t1%2Bczj66N5%2Fg3bfwhBmGEq6YCXy2xn%2FEA%3D&reserved=0>
> ===
> It is as ugly as an ugly thing (I'd say what I thought but I'd like more than a  mod to get to read this).

Sure is.

Step 1 in getting to being able to clean it up was converting the backend that implements it to C++ with clearly defined objects instead of a rather quirky collection of macros. That’s in the current “unstable” and will be released in 3.0.

Step 2 is to convert the corresponding objects in libgnucash/engine to C++ objects with proper constructors so that creating an object doesn’t involve calling a bunch of property setters (one at a time!) that want to commit the object and write it back to the database. That will be my focus for the next development cycle.

Once that’s in hand we can consider refactoring the schema into something a bit more reasonable and get away from sucking the whole DB into memory at load time.

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7C6ee9ecfa03c24c97580d08d56a5d2671%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636531870670279982&sdata=hTrghqjNt8XEYkE05%2FGtO7YQQre21RRVh%2Fm9LZMP8LY%3D&reserved=0