attached txn data [WAS: Re: http://bugzilla.gnome.org/show_bug.cgi?id=336843]
Josh Sled
jsled at asynchronous.org
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
<http://cvs.gnome.org/viewcvs/libgnome/libgnome/gnome-open.c?rev=1.2.2.1&view=markup> : 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 freedesktop.org spec along these lines
<http://freedesktop.org/wiki/Standards_2fmime_2dactions_2dspec> 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
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; 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 : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060706/3e0b5e60/attachment.bin
More information about the gnucash-devel
mailing list