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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel