GNUCash Development Plan wrt budgeting

[Christian Stimming]

Hi Jeff,

thanks for the detailed write-up about the areas where you would like to see 
improvements. Did you intend to potentially do some coding yourself? Did you 
intend to pay somebody to do (parts of) this? This wasn't clear from your 
original message. Here's what I would suggest if you intend to do some coding 
yourself:

Am Montag, 13. Februar 2012, 16:12:52 schrieb Jeff Kletsky:
> * Need a way that my wife and I can quickly see how we are doing against
> budget
>    - Scheme rendering is painfully slow --
> https://bugzilla.gnome.org/show_bug.cgi?id=612215
>    - Existing reports are hard to read and have poor usability, even on
> desktop screens
>    - Single-user access means that you can't just "pop in" to see a
> report, even if it were usable

If you want to get away from the slow scheme rendering, there are two ways in 
which to proceed: Either you implement some rendering system that runs much 
faster (or speed up the existing one significantly), or you implement a new 
view widget similar to the "account hierarchy" that will show the live numbers 
and doesn't need an extra rendering step.

As for #1: The existing rendering system is awfully inefficient, regardless of 
the actual scripting language. The numbers are calculated way too many times 
instead of doing a proper caching of intermediate results. There is a huge 
potential for improvement here, even if you stick to the rendering step and 
also stick to scheme. On the downside, I think nobody really understands the 
logic with scheme functions and C query functions and hand-written scheme or C 
code. I doubt anybody would be able to successfully identify the inefficient 
parts in the current rendering system.

Writing a different rendering system in some scripting language of your choice 
for your particular requirements might be an interesting way to go. On the 
other hand, the odds for success are even more unsure here.

As for #2: Writing a new widget is always possible, so IMHO out of the 
mentioned possibilities the odds for success are highest with this one. On the 
other hand, writing a Gtk widget either in C or (using the new glibmm wrappers 
in src/optional/gtkmm) in C++ is a rather unexciting task. You would set up 
the expected GUI layout in glade, then code a lot of C or C++ code to connect 
this to the number calculations. This is similar to the existing (bad) budget 
editing window. I'm rather sure it is not difficult to do this a lot better 
than the budget editing window, but it will be a lot of very tedious coding 
work. Not really difficult, just a lot of work.

> * Would prefer if we could access current actual-vs-budget numbers from
> any modern browser, including iPad, iPhone, and Android

Not immediately possible. Would require to use a SQL database as storage 
(mysql, postgresql). But: Recently somebody on this list announced a php 
wrapper for accessing the SQL database. Maybe it would work to run php on some 
webserver to access the gnucash SQL database. But this asks for a whole lot of 
authentification and so on.

> * Budget creation UI has severe usability issues including:
>    - Rendering/scrolling (column and row headers disappear is the most
> annoying)
>    - Can't "tab" to next cell for quick entry
>    - Can't "fill right"

Absolutely. Bothers me each time as well. I think this table-style editing 
widget can probably be rewritten with not too much effort, but this time 
getting the editing behaviour right.

> * Budget code is just messed up with respect to internal representations
> vs. UI display -- https://bugzilla.gnome.org/show_bug.cgi?id=612214

No idea about this one.

> * Budget should distinguish between "no budget established" and "zero
> budget set" -- For example, I may have a budget on Expenses:Gifts at
> $100, but not have a budget set for either Expenses:Gifts:Alice or
> Expenses:Gifts:Bob. Having an expense in Expenses:Gifts:Alice of $50
> should not be an "over-budget" situation for that account, nor should
> having $60 in Expenses:Gifts:Bob of $60, but I should see an issue at
> the Expenses:Gifts roll-up level.

Yes, but this asks for a better definition of what the budget functions should 
be able to do and what you will have to do yourself by setting up the account 
hierarcy the right way.

> * In some cases it would be beneficial if a budget could either or both
> indicate a limit on the total at a roll-up point, as well as an
> incremental amount (You can spend $100 on gifts, in total, but no more
> than $10 on gifts that haven't been assigned to a sub-account)

Same use case issue: Different users will want this to behave differently. 
Maybe this is rather a question how you set up your account hierarchy and your 
personal conventions about the spending categories?

> * The ability to determine if a budget is balanced (and, if not, the
> residual difference and sign), especially while working on the budget,
> is difficult. The reports related to budget balance have the same kind
> of problems as the actual-vs-budget reports. I define "balanced" when my
> budgeted changes to assets, liabilities, expenses, and income are
> zero-sum in an accounting sense.

I agree the existing tools don't for this case. I personally check for the 
balancing by setting up the budget in some spreadsheet software. On the other 
hand, you can think of very many different use cases here as well: What should 
the budget be balanced against really?

> * Because the tools within GNUCash for budgeting are so rough, I end up
> working up my budgets in Excel. It would be on my wish list to have an
> import/export feature.

There's a user-contributed export tool for OpenOffice, see contrib/gnuc2ooo.py 
and the URL in contrib/README. Maybe this helps? Also, writing yet another 
import/export plugin is much easier now that there are the python wrappers 
available for use. If this is important for you, I'd suggest writing an import 
or export plugin with python.

> I know it is a pretty long list, but I'd be happy to contribute thought
> or design feedback either here, on a wiki page, or directly, as it most
> makes sense. I've looked at the C code in the past and thought about
> some approaches, but the edict that everything needed to be backward
> compatible made things pretty horrendous. Especially after looking at
> the SQL schema in my current plan to implement off-line budgeting and
> reporting, I really dislike KVPs as ad hoc object extensions.

KVP are a compromise between keeping room for future extensions and still not 
breaking data file (XML) compatibility too easily. I agree they have severe 
downsides as well, but currently we don't have easy solutions available that 
cover the same possible extensions.

Off-line budgeting and reporting is just fine as well.

Best Regards,

Christian