Sorry to go back a few days here...
Tripp Lilley wrote:
[not Matthew Vanacek wrote:]
-1I don't want to put a dampener on this, but I think a clearer focus on what is to be done is a better approach than for someone to go out and start coding what they would like to see.
If each of the groups coded what they wanted, we'd have code for two
different ways of doing things, and could see / feel / fix those ways
until they either came into union or it was obvious that there was no
union to be had. Either way, we'd have code.
Yes and no. That sort of makes sense if you have coders a-plenty. Suppose he is the only coder that steps up on this one... yet suppose the consensus is overwhelming for the other "camp"? In the scratch-your-own-itch sense, of course the one doing the volunteering can work on whatever they want. But in the altruistic-community-open-source sense wouldn't it be better to implement what more of the users want?
That being said, (and given I am a few days behind on this thread), I agree with Matthew that coding ahead of designing is not a great idea, regardless of whether you have one group or two.
But I also think that what Darin is suggesting IS flexible enough to cover both "camps".
I also agree (was that also Matthew?) that separating the budget from the accounts is more flexible. As I understand what he is saying: it is not that the budgets and the accounts are separate and completely unrelated. It is that they start off separate (in the data model), and you CAN tie each budget item ("category" as I think Darin named it) to one OR MORE accounts. The "OR MORE" is the key here as I see it because it is what lets you handle both camps.
The person with sub-accounts in his Chequing account can tie a budget category one-to-one with his Assets:Chequing:whatever subaccount.
The person who wants more high level budgeting can have a "Food" budget category that ties to Expenses:Restaurants, Expenses:Groceries, and Expenses:JunkFood.
And it appears that that is what Darin has proposed.
Just my take on what I've been reading.
Cheers.
~Martin
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
