Patch to partially add recursion to budgets

[Gregory Alexander]

Alright, I have a patch.

This may start a flame, but I added a new GNC_ERROR_UNSET error code.
I added this because none of the existing errors was really
appropriate for a value that simply wasn't set yet.  I'm open to other
names like GNC_ERROR_UNINITIALIZED, and would reluctantly change it to
GNC_ERROR_ARG if there are strong objections to adding a new error
code.  I already caught one place where the number of errors was
hard-coded, so I replaced that with a new GNC_ERROR_MIN value.

User interface changes:

1.) Budget values of 0/1 are now displayed when editing as $0.00 (as
appropriate) instead of being left blank.
2.) If the user removes all text when editing a budget value entry, it
will be initialized to GNC_ERROR_UNSET.
3.) GNC_ERROR_UNSET is displayed when editing as a blank budget value.
4.) cleanup/debug: Other errors display as "error" when editing.
5.) In the existing budget report, entries with a value of
GNC_ERROR_UNSET display as "." instead of a currency value.  Other
errors continue to display as a single "$" (as appropriate.)

What I haven't been able to figure out is how to have new budget
entries default to GNC_ERROR_UNSET instead of 0.  I think changing the
default to GNC_ERROR_UNSET would be the correct behavior, although
again, this is open to discussion.

Comments, concerns?

Thanks!


BTW, I'm also working on a fancier budget report, but it isn't
currently in a state appropriate for public consumption (read: I
naively reimplemented gnc:numeric-add, among other ugly things.)  I'll
submit that in a separate patch once I get it cleaned up.



Replies below here, but mostly just agreeing with what you said.

On 9/28/06, Chris Shoemaker  <c.shoemaker at cox.net> wrote:
> On Thu, Sep 28, 2006 at 02:30:16AM -0500, Gregory Alexander wrote:
> > Now, let's assume the user doesn't actually care about the Non-Bills
> > category.  It's just a placeholder (I can come up with some better reasons
> > for this, but I want to keep using the same account structure.)
> >
> > ...
> > The user would probably prefer to have one of the following happen.
> >
> > Option 1 (what I suggested earlier): fill in from the bottom-up.  This gives
>
> I'm not so sure this is generally good behavior.  Imagine that the
> user only cares to budget for _some_ of the children accounts, and not
> the parent.  In that case, using the sum of the budgeted children as
> the parent's budgeted value isn't correct.

I'm not convinced by your budget for _some_ argument, since they will
be counted in the actual total for that category.  However, since the
overall budget for the parent may be different from the sum of the
children, I agree that automatically summing isn't a very good general
practice.  Since there isn't a clean or easy way to add this as an
option to the interface, I agree that the correct behavior is to not
implement summing.

> > Option 2: Mark entry as unbudgeted.
> >
>
> Hmm.  I expected that the normal usage of the budget report would be
> to only include the accounts that you budgeted for.  But, I can
> imagine some cases where it might be interesting to see the accounts
> you budgeted for alongside the accounts you didn't, in the same
> report.
>
> That sounds useful.
>
> > Does this seem like a more reasonable path?
>
> Yes, it does.  And easier, too.  It could involve:
>
> 1) return one of the of the gnc_numeric error states from the
> get_budgeted_value() when it was unspecified.
>
> 2) Allow set_budgeted_value() to "unset" the value if a bad numeric is
> supplied.  (or, provide an unset_budgeted_value()).
>
> 3) Teach the report to do something pretty for unspecified budget
> values.
>
> Are you interested in patching that up?

See above.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_budget_blank_1
Type: application/octet-stream
Size: 3762 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20061002/f238192c/attachment.obj