--enable-debug?
--verifydb and
--fixdb command line arguments mean that QHacc might lose
some of my data?
--home option. The steps are simple:
If you don't like using the --home option, you can alternately set a QHACC_HOME environment variable in your shell. If you use any of the bourne-like shells, then type
export QHACC_HOME=/home/ryan/.qhaccsetenv QHACC_HOME /home/ryan/.qhacc--import
option.
If you keep your old transactions in a checkbook, then there isn't any way around entering them manually. However, QHacc has many useful features for speeding the process. First, change your preferences to use "Auto-Complete on" all or new transactions. With this option, QHacc will try to use data from already-entered transactions on the new transactions. After typing in the payee, QHacc will supply the sum, memo, and double-entry account field automatically. If there is some ambiguity for a payee, you can go to the sum field and press the up and down arrows for other payments from that payee. Another useful feature is to highlight the last transaction entered, and use the "i" key instead of hitting the spacebar over "<new>" button to create a new transactions. This makes the transaction editor use the date from the already-entered transaction as the date for the new transaction. Hitting the spacebar uses the current date, which is probably annoying if you're trying to enter old transactions.
qhacc --export /tmp). The upgrade
plugin only works against QHacc's native file format, so if you use
some other database, you must create a native export.
qhacc --home
UPG:/tmp). This will upgrade your old data and start a new
instance of QHacc for you to check the results of the upgrade. Save
and close the application if everything looks okay.
qhacc --create
PSQL:qhacc). This is a good practice for all upgrades
because the upgrade process may change the structure of the data. If
you use a database backend, for example, the table structures may
change, any these changes must be accounted for.
qhacc --import
/tmp). This completes the upgrade.
Upgrade plugins work from one revision to the next, but they do not work for more than one revision. That is, if the data format changes from version 1 to version 2 and from version 2 to version 3, the plugin provided in version 3 assumes the datafiles are in the format of version 2.
Note: It has been brought to my attention that upgrading from v2.4.5 to v3.0
can be problematic for people using a decimal separator other than "."
in their datafiles. To fix this, run the following script before using
the upgrade plugin: sed -e 's/\([0-9]\),\([0-9][0-9]\)/\1.\2/g'
transactions > tmp && mv tmp transactions. This code simply looks
for comma-delimited sums and converts them to decimal-delimited ones. If
you are using something besides a comma, make the appropriate changes to
the script.
Note also that there is a bug in v2.4 when using single-entry
bookkeeping that also prevents the upgrade plugin from working
satisfactorily. This bug can be overcome with the following command:
awk -F\| '{printf
"%s||%s||%s||%s||%s||%s||%s||%s||%d||1\n",$1,$3,$5,$7,$9,$11,$13,$15,NR}'
transactions > tmp && mv tmp transactions. This code simply
updates the transactions file and assigns a new splitgroup to each
transaction. (QHacc no longer uses splitgroups, but some older versions
do.) This is not safe to run if you are using double-entry bookkeeping,
but the program behaves correctly in that case anyway.
--enable-debug?
--enable-debug option to
configure. That option was removed in version 2.0. The reason is that
debugging information is now controlled at runtime instead of
compile-time, and that control is much more fine-grained than the
--enable-debug provided. There are currently 6 levels of
debugging/error handling information:
--enable-debug also used to enable compilation with the
-g option to gcc. That option made the compiler include
debug information in the executable. The same behaviour can be obtained
directly through make by using: make CXXFLAGS="-O2 -g"
First, you need to start with a .ts file. This can be created using the lupdate.info file included with the sources in the src directory. Edit that file to include your i18n code. (i.e., qhacc_de_DE for German; qhacc_en_US for American English.) Then, run lupdate on lupdate.info to create the ts file. If you have trouble, contact me, and I'll be happy to make the ts file for you. If you followed the example, running lupdate should create a qhacc_de_DE.ts file.
The ts file is a simple XML script that contains the needed translations and their translated texts. You can edit it by hand, though Qt provides a tool called linguist that significanly enhances the experience. When you are done with the translation, call lrelease to make a .qm file. If you used linguist, there is an option to create a release from the open ts file. This qm file contains your translation QHacc. So how do you use it?
Using the qm file is a bit clunky at this time, though it does work. To use the qm file, just set your LANG and QHACC_LANGDIR variables. The LANG variable should be whatever your international code is, and QHACC_LANGDIR is where the qm file is. To continue our example, a German user would set LANG=de_DE, and QHACC_LANGDIR to /usr/local/qhacc/share, assuming that is where they put the qm file. Restart QHacc, and it should be in your language. (Localization--things like decimal point and currency symbol--is slightly different from internationalization. Right now, QHacc's support for l10n is limited to the options in the preferences dialog. There is no automatic l10n support.) By default, QHacc will install the available qm files into /usr/local/qhacc/share.
QHacc is currently available in English, Spanish, and Bulgarian. I'll stand by the English translation, since that's the only language I can reasonably speak. I also wrote the Spanish translation, but that's a bit more of a stretch for me. The Bulgarian translation was kindly contributed by a user, and I can only assume it is correct. I am very grateful for it, that's for sure.
If you are interested in translating QHacc, I would love to hear from you. If you're a bit worried about the amount of work, it is VERY easy to make a translation.
As for QHacc, the instructions are a bit hokey, but they work:
Note: If all this smacks of a massive kludge to get QHacc running on a
totally unfamiliar platform, I'll level with you: I'm not really a
Windows programming master, but I can get by.
Note 2: Porting QHacc to Windows was actually extremely easy. It took me
a grand total of one evening to do it. Qt is a fantastic toolkit.
qhacc --import QIF:<account name>:<qif
filename>
qhacc --reconcile QIF:<account name>:<qif
filename>
--create option for displaying the commands
necessary for creating a database from scratch.
qhacc --create <plugin id>:<databasename>
to create a script that can create the QHacc database. (QHacc
won't do this automatically.)
--home option. I will note that the SQLite/LocalFile Hybrid
plugin is the easiest to setup because reads and writes to QHacc's
native savefiles. After loading the files, however, it uses an in-memory
instance of SQLite to do all the querying and updating, and writes the
data to disk on saves.
qhacc
--accounts against an identical dataset 83 times. The dataset had
33 accounts, 6,000 transactions, and 12,000 splits. Here are the
unofficial average results, for the curious:
| Plugin | User Time (s) | System Time (s) |
|---|---|---|
| Native | 19.50 | 0.05 |
| XML | 22.37 | 0.08 |
| PostgreSQL | 0.69 | 0.02 |
| MySQL | 0.69 | 0.03 |
| SQLite | 3.01 | 0.20 |
| Hybrid | 6.96 | 0.05 |
So, why use an integer instead of a long integer (which would allow
transactions of up to $92,233,720,368,547,758.08)? There's no particular
reason, other than QHacc is the "Q Home Accountant," not the "Q
More Money Than Has Ever Been On The Earth Ever Accountant." I'm
perfectly willing to limit QHacc's scope of use to people and families
that have less than $20M in working capital.
To give you an estimate of how long a plugin takes to write, I added support for SQLite databases in the span of two hours one night. I had no knowledge of SQLite previous to starting coding. There were a total of three non-trivial functions to write, consisting of a total of 50 lines of code. It's that easy.
Of course, QHacc uses plugins for graphing and reporting support as
well. The interfaces for these plugins are also in the plugins.h header
file, and samples can be found in the plugins directory of the
distribution.
/usr/local/qhacc /usr/local/qhacc/bin /usr/local/qhacc/lib /usr/local/qhacc/lib/plugins /usr/local/qhacc/lib/plugins/db /usr/local/qhacc/lib/plugins/import /usr/local/qhacc/lib/plugins/export /usr/local/qhacc/include /usr/local/qhacc/share /usr/local/qhacc/share/htmlBut QHacc uses Autoconf, so just about all the locations can change. For the most part, that's not a problem, except when it comes to plugins. Currently, plugins get installed into the lib directory and links get created in the appropriate plugin directory. However, if you change where the libraries go, the links may not work, and none of the plugins will be loaded.
The solution to this problem is the preconf file. More information
about it can be found here. This file
goes in the root of the QHacc installation (you can find this easily by
running qhacc-config --qhaccroot), and can include the
token "PLUGINDIR" to point to where the plugins can be found. You'll
probably also need to recreate the links or move the libraries from the
library directory.
So what if you installed the binaries one place, the libs somewhere else, and you deleted everything else? That's a little more complicated, but still doable. Just find your qhacc executable. It's actually just a shell script, so you can edit it directly to change the QHACC_ROOT variable. Point that to the new installation directory (where the preconf file can be found), and change the LD_LIBRARY_PATH variable to point to the lib directory. Again, if the plugins aren't where QHacc's expecting them, you'll have to recreate the links or move the libraries.
I guess I should note that relocating QHacc isn't exactly for
beginners. You should be familiar with your system and administering it
in general before attempting these procedures.
--verifydb and
--fixdb command line arguments mean that QHacc might lose
some of my data?
--verifydb and --fixdb are modes
I created for use during testing. I noticed that I was corrupting my
data when I would manually enter things into the datafiles that didn't
synch up to what was in the other datafiles, so I wrote the functions to
tell me when I had made such a mistake, and I figured they were simple
enough the leave in the code once it was released. In normal operations
(using stable releases), it is extremely unlikely that your database will
become corrupted. If it does, it's a serious bug.
At this point, I will note one thing in favor of PostgreSQL: it makes
the --verifydb and --fixdb command line
arguments totally superfluous. PostgreSQL enforces referential integrity
in its data, so it cannot become corrupted in the same manner as some of
the other plugin databases can, even if you're trying to corrupt it.
--home extprg:</path/to/qhacccvs.sh>:<QHACC_HOME>
as your QHACC_HOME. (The qhacccvs.sh script assumes the repository name
is "home," so you may want to change that before using it.) Using the
External Program plugin in conjunction with the qhacccvs.sh script will
force QHacc to check out your QHACC_HOME from CVS before starting up,
and save it back to CVS on every save.
The QHacc package comes with a script that gets generated at compile-time so that other programs can use the same libraries. That script, uncreatively enough, is called qhacc-config. That's what KHacc is looking for when it's getting built.