Coming soon: KMyMoney 1.0
In 2005, GnuCash appeared to be at a low point. The port to GNOME 2 still wasn't done, distributors were talking about dropping the package, and developer morale seemed low. But when looking at KMyMoney, your editor saw a different picture:
Since then, GnuCash has produced a number of well-received releases and appears to (still) be the dominant program for personal finance management. Active development continues, with the long-defunct database storage option poised to make a return in GnuCash 2.4. On the KMyMoney side, instead, the 0.8 release that your editor reviewed is still the current major stable release; the 0.8.9 update came out in March, 2008. For whatever reason, things seemed to stall for a long time; if there were a need for more evidence that your editor's predictions deserve ridicule, this would be it.
Behind it all, though, the KMyMoney developers have continued their work. As of this writing, the 1.0 release can be expected almost any time. Your editor pulled a copy from the project's CVS repository to see where things stand; the short answer is that KMyMoney has taken some important steps toward being a full-featured personal finance management program. For many (if not most) users, it should be all they ever need.
Building the tool was relatively straightforward, with only a couple of "./configure; install a missing dependency; repeat" cycles required. One interesting surprise was that KMyMoney remains a KDE 3 application. Work is being done to port the code to KDE 4, but the developers are not making any promises about completion dates; getting the 1.0 release out the door seems to have taken priority. Despite being a KDE 3 application, KMyMoney will run fine in KDE 4 environments.
KMyMoney 0.8 was a reasonably polished application; the 1.0 release
continues that tradition. Some of the artwork has been toned down a bit;
the windows tend toward a relatively sober blue and grey presentation now.
As a general rule, the application's presentation is clean, readable, and
usable.
As with previous versions, KMyMoney includes an importer for files in the GnuCash format. It gets the job done, mapping GnuCash entries into the KMyMoney way of doing things without any real trouble. There's no support for the business features of GnuCash - KMyMoney is not looking to be a business bookkeeping application - but most users will never notice.
Saving a file in KMyMoney 1.0 brings a nice surprise: the application has been integrated with GPG to encrypt financial files by default. For a user who already has a GPG key, it all works automatically, with no additional configuration work required at all. More advanced users can configure the application to encrypt for multiple keys or (to protect against disaster) for a special backdoor key controlled by the KMyMoney developers. The program also advertises the ability to save a file to an SQL database. According to the documentation, SQLite, MySQL, and PostgreSQL are all supported, but your editor was only offered SQLite as an option - and it didn't work. The database storage feature looks like something that is expected to mature in future releases.
One of your editor's grumbles with version 0.8 was that transaction entry
was relatively hard; it was more mouse- and keyboard-intensive than
GnuCash. Version 1.0 has improved things somewhat. If one knows the magic
control-insert sequence, it is now possible to enter transactions with no
mouse clicks required at all. Annoyingly, check numbers cannot be
incremented or decremented from the keyboard; one can only type in the new
number. Beyond that, it still seems to require too many tabs, and
the single-line GnuCash presentation still seems more natural than the
two-column form used by KMyMoney, but things have gotten a lot better.
There is a budgeting and forecasting module built into KMyMoney 1.0. The application can put together a provisional budget based on past transactions, then track how the user is doing against that budget in the future. The forecasting code can extrapolate trends into the future, giving the approximate date when the money runs out and foreclosure proceedings begin. The program was, however, unable to forecast when your editor's long-awaited federal bailout would arrive.
A GnuCash feature totally missing from KMyMoney 0.8 was graphical reports.
Version 1.0 fills that gap. The tabular reports available in KMyMoney
have always been nicely done; now it's possible to get the information in
manager-friendly pie-chart form as well. The value of this kind of plot is
debatable at
best, but there is a certain eye-candy value to them and some of the other
plots are more useful. It is, in any case,
a feature checkbox that the project needed to fill.
Some progress has been made with online banking; European users with banks supporting HBCI or OFX will be in luck. Your editor, lacking such a bank, was unable to test out those features. Importing of downloaded bank and credit card data is also now supported; the only working format, though is QIF. The GnuCash importer provides an intermediate window showing the transactions to be imported and providing an opportunity for the user to change what will be done. KMyMoney, instead, just dumps the transactions into the specified account; the user must then go through a mouse-heavy process to classify transactions that the program does not recognize. All of the needed functionality is there, but it's a bit rough around the edges.
In summary, KMyMoney 1.0 is a solid application which now has support for
all of the features most personal finance users will need. It appears to
be quite stable; your editor was unable to make it misbehave or crash - at
least, when not trying to use the database storage feature. The developers
behind this tool should feel content as they head toward their 1.0
celebration. Thanks to their work, Linux users have two high-quality
personal finance tools to choose from.
Posted Aug 20, 2009 5:10 UTC (Thu)
by hisdad (subscriber, #5375)
[Link]
It makes things easy that previously were so tedious.
Budgeting is good, with a flaw if your fiscal year is not a calendar year, it truncates the budget.
Excellent piece of work.
--john
Posted Aug 21, 2009 8:03 UTC (Fri)
by golding (guest, #32795)
[Link] (2 responses)
I use Enlightenment without Gnome and GnuCash still seams to be best fit.
Posted Aug 21, 2009 18:34 UTC (Fri)
by morhippo (guest, #334)
[Link]
Posted Aug 22, 2009 9:51 UTC (Sat)
by jospoortvliet (guest, #33164)
[Link]
Posted Aug 21, 2009 18:46 UTC (Fri)
by jhhaller (guest, #56103)
[Link]
Posted Aug 27, 2009 23:01 UTC (Thu)
by astrophoenix (guest, #13528)
[Link] (5 responses)
'gramps' has already moved to a database storage model, and I hate it. I liked doing crazy ascii type stuff with the data, like being able to read it! or tweak stuff by hand occasionally. or manage it using git or mercurial. now if I simply open gramps, then close it, I get a bunch of binary changes that are meaningless; I didn't actually change any data.
can anyone explain the advantage of using a database instead of an xml file for something like a personal accounting app??
frustrated, and loving ascii,
Posted Aug 27, 2009 23:57 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
you can implement all this yourself (but not easily in a ascii xml file), but at that point you have duplicated the hard stuff that a database does.
once you take the effort of converting your software to work with a database (delegating the data integrity, searching, indexing, etc tasks to the database) with an embedded database like sqlite, it's a small step to move to a full database that can offer you additional features (like replication and failover) for no additional application complexity (beyond the change to talk to that sort of database)
the application should have the ability to do import and export through flat files, but it makes a _lot_ of sense to use a database instead of flat files (and especially instead of ascii XML files) for the main datastore.
Posted Aug 28, 2009 15:29 UTC (Fri)
by astrophoenix (guest, #13528)
[Link] (1 responses)
but I wonder where the crossover point is: i.e., how big does your dataset have to be before a user using the gui app will notice any difference between a database backend or an xml backend?
because the other tradeoff is that it's a LOT simpler for a USER of the data to do unexpected things with the data if it's ascii.
I suppose I could just export it to the ascii, do what I want with it, and then get used to the routine of importing it back from the ascii each time I run the gui app.
before I was really thinking about the tradeoffs, the idea of a Free software project putting the data in a hard-for-the-user-to-use format seemed a bit jarring; technically the database format is still useable, but getting database redundancy and failover is a tad bit more work and more fragile than committing a text file to git or mercurial.
Posted Aug 28, 2009 16:23 UTC (Fri)
by dlang (guest, #313)
[Link]
when making a change (no matter how trivial) you would need to write a modified version of the entire file and do the appropriate fsyncs (for the file and the metadata)
with a database you just tell the database what changes you want done and it makes the changes (probably fare more efficiantly than you will, as well as being far less likely to have missed some corner case)
searching a xml text file involves reading the file, parsing it, then walking the data in memory (or reading the file, parsing it as you go, and aborting the parsing when you have the data you need)
databases have many tricks that they can use to speed the data access (indexes, binary data representation, etc)
as for locking the data in a 'hard for the user to use' format, I would say that putting it in a standard database that many different tools can readily access (in many cases making it look like a spreadsheet, but including dump/restore to/from flat text files) makes it pretty easy to get at the data.
also, keep in mind that one commonly used database for this is sqlite. that database engine keeps all the data in one file (just as easy to check into a version control system), and does not require communication to a seperate daemon. it basicly acts as a file manipulation library in your software, so it has very low overhead.
as for redundancy and failover, that can mean many things. if you want to have the data stored on a central box (rather than sitting on someone's laptop that can break, get lost/stolen, etc) databases can do failovers to backup boxes transparently to the user
for a single home user this (usually) does not matter, for a small business this can be critical.
In addition, with a database back-end it is relativly easy to allow multiple people to share access to the data at once. again, not a feature that a single home user normally cares about.
Posted Aug 28, 2009 16:43 UTC (Fri)
by jordanb (guest, #45668)
[Link] (1 responses)
Actually if you're trying to manipulate the data 'out of band', or make an external tool that acts on a program's data, then sqlite is a dream format since it gives you a very powerful structured data manipulation interface (the SQL language).
If you want to keep the data in version control, you can do a data dump from the database file into a text file and then check *that* into VCS:
echo ".dump" | sqlite3 grampsdb > my_gramps.sql
You can also do that, of course, and use your regex masher on that sql file, and then import it back into the database. ;)
Posted Aug 28, 2009 16:48 UTC (Fri)
by dlang (guest, #313)
[Link]
OFX Working Well
Coming soon: KMyMoney 1.0
Coming soon: KMyMoney 1.0
Coming soon: KMyMoney 1.0
Enlightenment or any other environment... The only two things about KDE
apps are the development platform and the community. In every other area
they're just applications which can run anywhere - from win and mac to KDE
and Gnome...
Coming soon: KMyMoney 1.0
Coming soon: KMyMoney 1.0
astrophoenix
Coming soon: KMyMoney 1.0
Coming soon: KMyMoney 1.0
Coming soon: KMyMoney 1.0
Coming soon: KMyMoney 1.0
Coming soon: KMyMoney 1.0
