Dave Peticolas <[EMAIL PROTECTED]> writes:
> So we would have a 'long' name and a 'nickname'?
Sure, though in my original incarnation, I was thinking of an
potentially limitless number of nicknames depending on the view that
the account was in. In fact the name would be a part of the view
(basically the path through the tree (GList of GLists) that you took
to get to the account, not a field in the account itself.
i.e. Income:Consulting:GreatEnterprises might refer, in a given "view
tree" to the account whose "true name" was "GreatEnterprises
Consulting Payments". The name Income:Consulting:GreatEnterprises is
just the set of names you hit when you go down a particular "view
tree" to get to this account.
(("Income" . #f)
...
(("Consulting" . #f) ...
...
(("GreatEnterprises" . Account*0xF4423A)
...)
...)
...)
A name with a #f just means that it doesn't have any associated
account, though one could be added later. Also, I'm just using
scheme-notation for illustration. As I mentioned, I would plan on
implementing this in glib.
> Do you mean ditching engine-cached subtotalling? We should probably
> get rid of that, as the issues with currency translation are going
> to make it a bit complicated, but we should still display subtotals
> in the hierarchy.
Mostly what I meant is that in some hierarchies, subtotalling's not
going to make any sense, at least in certain parts of the heirarchy,
so perhaps it should be a per-level option, or perhaps it should only
become active if all the sub-account types match properly, or both...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
