Codehelp blog

This is more of a reminder to myself to investigate this within GPE. The basic problem is that many events recorded in applications like gpe-calendar have a direct relationship with a specific person in the contact database and can also be linked to records in the expenses database. Expenses are relatively easy if the time of the expense occurring can be related to the duration of the event but a formal link may be more useful for extra granularity.
Relating an event to a person would typically involve the event being a work placement, a project name, a customer name or the name of an organisation. It could link an event to the organiser of the event or provide a quick lookup for the location of the event to eliminate entry duplication. (Why have the address of the event in the event record if the address is already in the contacts database? Equally, why have the dates of an event in the contact record for the organiser of the event when the same organiser may well be putting on a similar event again in the future?)
I'm thinking that gpe-calendar and equivalent applications could have a field within the event record for an ID in the contact database and a preference setting for the "category" of contacts to be shown in that field, e.g. Business or Conferences. Entry of the association would simply be a drop-down box of contacts that have the appropriate category set. A similar associative field can be implemented in expenses.
This all makes creating an invoice much more reliable. The current pilot-qof method depends on the user specifying the name of the contact as the description of the event and the "vendor" or "city" of the expense.
I'm sure there are other uses for associating events with contacts and/or expenses.
No time to investigate this just yet but it is another essential step in migrating PIM into a business-friendly format, SBIM (for want of a better name).
Small business support is lacking in current free software programs, IMHO. The applications that do exist do not work together to ease the administration burden of a small business the way that the system tools work together to ease the sysadmin burden. Understandable, yes, but small businesses need this kind of support to migrate to free software. "Joined-up thinking" is the buzzword but it's basically eliminating duplication in data entry/retrieval, associating business data across disparate data sources and enabling queries and data mining to support tax calculations, business plans, time management, project management, customer data handling ... the usual small office/home office workload.
I'm inevitably concentrating on data integration in an embedded devices like iPAQs, smart phones or blueberry-type handhelds but similar requirements need to be met within the rest of the free software world too. Once I've got time to investigate this, expect some threads on debian-devel looking at how Lenny could be made more business-friendly; not seeking an "Enterprise" version but simply making it easier to administer a small business using Debian.

If anyone was wondering why I've been quiet / claiming to be busy for the last week or so:
gpe-cash finally has a stable "main window" that supports creating new accounts along with the transactions and splits necessary to support an opening balance in the gnucash objects.
Current SVN requires current QOF CVS, accessible via the respective SourceForge repositories. gpe-cash is nowhere near release right now - the actual balances don't show up for one thing and I still need to write the window that will allow the creation of transactions within the accounts - but one step at a time. I'll see about some screenshots eventually but the gpe-cash main window is quite similar to that of gpe-expenses.
The main side-effect of all this is a much improved SQLite backend for QOF that is closer to being able to properly support double-entry financial data.
Note this does not mean that GnuCash itself will be able to use the QOF SQLite backend - the GnuCash currency/commodity handling is incompatible with QOF so gpe-cash uses the currency handling from gpe-expenses which in turn came from pilot-qof and the range of currencies supported by the Palm Expenses applet. The currencies are directly equivalent to the respective GnuCash currencies but not all GnuCash currencies are supported by pilot-qof, gpe-expenses or gpe-cash. The biggest change in gpe-cash is that this conversion is now working so that the gnucash code sees a gnucash currency when actually it is handling a pilot-qof currency.
gpe-cash is GPL-3+ and single-user (== single-file or single-book) as well as single-currency. Adding multi-currency support is possible but not a priority.
Once gpe-cash is closer to release, the codebase will be able to support gpe-invoice using the GnuCash business objects which will interface with gpe-cash to create invoices from other GPE data and store the payments and charges in gpe-cash.
If multi-currency support can be achieved, it would be possible to create "gpe-shares" as a different add-on to gpe-cash, although that is only theoretical at this stage.
The SQL-type query support inherent in QOF, together with perl support for the XML backend data via libxml-qofqsf-perl and XSL support for same XML backend via datafreedom-qsfxsl should make report generation trivial. I may also be able to add QOF support to the still experimental quicklist. I also plan to include support for import/export from all the datafreedom packages with HomeBank data which is returning to a NEW queue near you quite soon . . .
Overall, I'm getting closer to having a full range of individual applications that achieve a long term goal - the breakup of GnuCash source code into small, individual tools in the Unix tradition, all built on SQL-type queries, multiple backends and generic data handling. (See data-freedom.) Down with bloat!

<rant>
It's about time users had free financial data as well as merely free financial software. The lack of data interchange between existing free software "financial solutions" is a scandal, IMNSHO.
The rest of the "Office" dataset have a range of file formats and a range of filters. Financial data relies on the horribly broken QIF file that was never designed to be a standard and OFX where support is horribly patchy and doesn't provide data interchange between programs on the same machine.
</rant>

Just completed the migration of the next version of apt-cross that is due to be uploaded once dpkg-cross pre2 can be uploaded to experimental. (This in turn is waiting for dpkg to support removal of the dpkg-cross diversions: #439979.)
AptCross:: has gone, replaced by Cache::Apt:: and the Cache.pm from NorthernCross is now called Lookup.pm for clarity.
This update solves a lot of niggles with the old apt-cross behaviour when dealing with non-standard repositories, CDROM archives, proxied mirrors and various other stuff that apt can cope with but which wget found difficult. (#440929, #442012)
Also, the entire package has migrated to GPL v3 or later - all the code was GPL v2 or later.
This means that emdebian-tools will also be migrating to GPL v3 or later when that is updated to use the new apt-cross and dpkg-cross code.
Sometime after Lenny, Cache::Apt:: will migrate into a source package of its own (on CPAN), allowing the apt-cross functionality to be merged into apt and the module to support other tasks in Emdebian.
In other news, gpe-cash is coming along and highlighting a few issues in libqof1, libqof-backend-sqlite and libqofexpensesobjects so there are improvements due there too. gpe-cash and gpe-expenses are also GPL v3 or later, as are deb-gview, quicklist (experimental) and pilot-qof now too.
Most have some machine-operable fields in debian/copyright and most have the new dpkg fields in debian/control.
Got a fix for gpe-bluetooth to upload tonight as well as (hopefully) the last go at getting homebank through NEW.

Homebank has had a few problems getting through NEW due to legacy problems from the original Amiga version (and it isn't ready yet) but I've been trying it out anyway and comparing to gnucash. Bearing in mind that I have done upstream work in gnucash (i.e. I like gnucash enough to tackle the massively scary gnucash source code) and have (almost) got used to the regular dependency hell that it imposes on my sid installation, I'm finding homebank quite friendly.
(See #441110, #441103, #441129 and #441363 for recent examples of gnucash causing dependency hell - again.)
(1:0 to Homebank).
Homebank is closer to the Quicken model with categories but internal transfers between accounts are supported to give some impression of double-entry. (1:1) My main interest is in data import/export because I've long been looking for a way to create invoices from PIM data e.g. in a Palm Pilot or similar. Homebank supports a CSV data import for data that can be handled as an invoice. OK, there's no fancy invoice printing but that doesn't bother me (I never used the gnucash invoice print support) (2:1 to Homebank) - my invoices are all electronic and I have to use the client system (MSDOS!). What I need is to create my own records of the invoices within my financial accounts and Homebank may be able to do that with far greater ease than gnucash. My data exists primarily in my Palm because I take and change my bookings on-the-move. I want to be able to HotSync my Palm through a query interface (pilot-qof) and XSL (datafreedom-qsfxsl) direct into a financial application that can correlate that data with the payments made into my bank by the client and thence with data from my bank statements to prepare data suitable for my tax report.
I'm thinking that if I can get half of the ease-of-use of Homebank into the rigorous double-entry support of gnucash in a small program (gpe-cash), I'll be doing very well.
One limitation of Homebank is the "wording" - the translations appear awkward and unfamiliar but that can be easily fixed. The link between "Archives" and "automated transactions" isn't clear - I think it means "templates" and "scheduled transactions". (2:2)
Homebank can't do all the things that gnucash can do but that is a weakness in gnucash, not homebank. (3:2 to Homebank) IMNSHO, GnuCash tries to do too much and that leads to an oversized and overly complex codebase as well as a dependency list that puts OOo to shame. The graph support in homebank is a lot better than gnucash and that is not the fault of libgoffice, it is entirely down to the choices made by gnucash upstream developers. Homebank graphs are fast, simple, intuitive and informative, displaying useful info at the first attempt instead of having to wade through the Options dialogue in gnucash. (4:2 to Homebank).
If I can work out some simple scripting that combines these external tools into 'HomeOffice' support in Homebank, everyone wins.
I've never liked CSV as a data format and the homebank main files are XML (like gnucash). Unlike gnucash, the XML appears sane and usable for XSLT - raising the prospect of creating reports directly from the homebank data files.
Homebank upstream have been very supportive of the various requests to assist getting Homebank through NEW so I'm hopeful that if an XML import/export method was proposed it could be included in future - especially if the donkey work is done by external tools.
This would tie in well with datafreedom-qsfxsl and datafreedom-perl. Initially, I'll look at XML->CSV - ugly, I know but at least Homebank can import data to be used as invoices; gnucash cannot. (5:2 to Homebank).

At the end of round one:
Homebank : 5 GnuCash: 2.

OK, gpe-bluetooth updated and migrated to unstable from experimental.
gpe-calendar updated (after getting it into testing finally) so libsoundgen can actually have a useful role.
gpe-shield updated in experimental.
Also begun discussions with GPE upstream about avoiding common names for library names (along the lines of existing policy on application names) and arranged to send all my .desktop file patches upstream too. That should make future updates easier.
gpe-expenses has also been updated in Debian to fix a problem building against the new library. gpe-expenses is already GPL-3+ and now deb-gview and pilot-qof have also migrated and the second pre-release of quicklist in experimental is also GPL-3+.

Just trying to get some data "out-there" on this issue because I'm seeing duplicate bugs being filed and I can't get any response from GnuCash Bugzilla - probably because bug-buddy is busy filing lots more duplicate bugs upstream about a problem that is entirely within Debian.
The latest upgrade of g-wrap is borked and this leads to the g-wrap binary being installed at version 1.9.9-1 when the rest of the g-wrap package is held back due to the transition from libgwrap-runtime0 to libgwrap-runtime2.
This broken transition breaks gnucash. A simple error message if only g-wrap is upgraded, a complete seg fault crash if guile-g-wrap is upgraded too.
So far, we have 3 bugs in Debian:

• 441129 gnucash: fails to start after upgrade of g-wrap 1.9.9


• 441248 gnucash: Do not start anymore after last unstable upgrade


• 441309 gnucash crashes on start

Please don't add any more. The real bug is 441103 in the g-wrap package and the fix is described in my response to 441248 as:

GnuCash is usable if you can revert to the version of g-wrap in

testing. I'm running it now with:

$ cat /etc/apt/preferences 

Package: g-wrap

Pin: version 1.9.6-3.2

Pin-Priority: 1001



Package: guile-g-wrap

Pin: version 1.9.6-3.2

Pin-Priority: 1001



i.e. there isn't anything wrong with gnucash and if g-wrap had

transitioned properly, the g-wrap binary would not have been upgraded

to 1.9.9 on your system until gnucash could use libgwrap-runtime2

instead of libgwrap-runtime0. With the correct dependencies set in

g-wrap, this whole gnucash problem would have been avoided cleanly.

There is a separate RC bug against gnucash because of this transition: gnucash: FTBFS due to g-wrap transition. which does NOT affect the currently installable and usable version of gnucash in sid.

Thanks.

I've found some time for quicklist, finally, to move the port on to a second pre-release. New additions include a Recent Files submenu and GtkHTML report engine but the Sort and Filter options are not complete and adding a new report is problematic.
quicklist is now ready for some translations (the first one identified a problem in pre1 that prevented certain strings from showing up as translated). Also added a prototype manual using docbook that I've made available as HTML for dwww and making the docbook file itself available to yelp.
Currently, I'm undecided just where QuickList will fit between pure-Gtk2 and pure-Gnome2. pre2 uses libgnomeprint and libgnomevfs but yelp would bring in the main gnome libraries so yelp is just a Recommends and only as an alternative to dwww:

Recommends: www-browser, dwww | yelp

I hope to find some time to fix the remaining bugs but if anyone fancies helping out, see http://quicklist.sourceforge.net/ and take a look at the current CVS prior to the pre2 upload. CVS provides a method to build the updated code docs for developers (rather than the Manual which is aimed at users) using doxygen - the version on the website is out of date. This includes a list of bugs and ToDo items - most of which are centred on removing the last vestiges of the original QuickList code and refactoring to make full use of libglib2.0-0 functions like GList and GHashTable instead of fixed length multi-dimensional arrays.