attached txn data [WAS: Re:]

Josh Sled jsled at
Thu Jul 6 18:35:53 EDT 2006

On Thu, 2006-07-06 at 16:40 -0400, Tim Wunder wrote:
> This strikes me as something that would need to go into split-register.c and 
> the file chooser would need to be called from a cell in the register. Am I 
> off base there? 

That's basically right.  It's a model/view approach, so there's a
view(ui)-independent model of the register and each of its cell types,
and a view-dependent implementation of the UI for each cell type.  So,
generally, there should be:
- register/register-core/gnc-mumble-cell
- register/register-gnome/gnome-mumble-cell
- changes to the split-register to include the cell

Of course,there's a register re-write in progress, so you should
probably coordinate and/or wait for that.

> Assuming the code belongs in the register, the next question is where. In the 
> register, there's a two line view, and a single line view. In the two line 
> view the user can enter Action and Notes. Would it be better to create a new 
> cell in the register (say "Attachment") that would display on the 2-line view 
> after Notes (under the Transfer account) or simply use the notes cell? 

It should probably be a seperate 'attachment' (or 'link') column, that
reflects the state of an attachment being present, and affords a control
for editing or viewing ("activating"?) the attachment ... though perhaps
the manipulation should be done through a menu/toolbar, not through the
cell itself --- like the attachment column in an email app.

> How would you go about enabling the user to select the contents of the cell so 
> that they can view the file (in whatever application)? Ctrl-Click to send a 
> file open command to the desktop environment (will that work?)? GnuCash is a 
> Gnome app, what happens if GnuCash is run in KDE (or some other DE)? How will 
> GnuCash know how to tell the DE to open the file?

Um, GnuCash is a GNOME app ... I think when it's run in KDE a little BSD
daemon is given its wings or something... :)

Seriously, though, the current front-end is for GTK and GNOME, so it
should probably ask GNOME to open the file.  For the first cut, though,
it's probably reasonable to do similar to what `gnome-open` does
<> : call `gnome_url_show(gnome_vfs_make_uri_from_input(...))`.

While it's nice to integrate into whatever environment the user's
actually running in, that's a bigger issue than us.  In particular, it
looks like the spec along these lines
<> is still
in a very early stage.

> The bug mentions a data store for the file. That seems reasonable. But that 
> would seem to indicate the requirement for some sort of preference that tells 
> gnucash where to store data files. And it begs the queston of how those data 
> files would get named/referenced. You'd also need to deal with the 
> possibility that the data file referenced gets deleted/moved from outside of 
> gnucash. 

Either gnucash manages the data entirely, or gnucash just holds
references to the data...

Managing it ourself has two options: a) treat data like (QOF) objects,
b) treat data like files.  The former is nice because it fits the rest
of the system, and will make sense in the context of a SQL backend.  The
latter is nice because it's pretty straightforward.  In both cases,
there needs to be some sort of attach/save file paradigm.

If we treat the data like files, but stil internally managed, a
(somewhat) simple way of implementing this option might be via
gnome-vfs, treating a single archive file (i.e., a tarball) as a
seperate file-system of the managed content.  It might even be
reasonable to insert an XML-safe version of that archive in the current
XML file (as a big base64-encoded blob, probably :( ).  If it's not part
of the datafile, then there's an issue about linking the datafile to the
archive file.  While this is a problem we already face, it's one we
should be working to eliminate, not aggravate.

As for naming these objects, gnucash's existing use of the GUID is a
reasonable way to name (and identify) the data objects as well as
associate them to a transaction --- either via a new field in the
transaction itself of just a new KVP-frame field.  At the same time, if
we don't retain the source filename, we probably need to record the
mime-type of the data as we receive it -- either provided explicitly or
derived from the file name (e.g., ".jpg").

Just holding references to external files is far simpler, but open to
referential-integrity problems as you mention.

I think a first cut should take URLs (file:, http://, cifs:, ...
whatever) and store them in the txn's KVP data.

Note that a URL like...

    data:image/djvu;base64,[base64'ed receipt image]

... is a nice compromise :) ... well, once gnome_url_open supports
data-scheme URLs, at least.

> This all makes it seem rather non-trivial to me. Am I making any sense here?

Yes, this makes sense.  There's a lot of unresolved pieces to this
enhancement, but I think it can be done in a simple way.

...jsled - `a=jsled;; echo ${a}@${b}`
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : 

More information about the gnucash-devel mailing list