http://bugzilla.gnome.org/show_bug.cgi?id=336843

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

http://bugzilla.gnome.org/show_bug.cgi?id=336843

Tim Wunder (Lists)
Bug #336843 was mentioned on IRC today and I feigned interest in it. I was
assured by warlord that "this is something pretty easy to do.  Hook a
GtkFileChooser to a menu item and load/save the result from/to the
current-txn KVP." So I started looking in src/register/ledger-core/ to see if
I could figure out how to "hook a GtkFileChooser to a menu item."
After wasting much time reading through C code that (at best) I can barely
read, much less understand, I figured I'd ask a few questions before deciding
whether this is a good RFE for a neophyte to attempt to tackle.

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?

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?

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?

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.

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

Thanks for listening,
Tim

--
Fedora Core release 5 (Bordeaux), Linux 2.6.17-1.2139_FC5
 16:15:01 up 8 days,  6:42,  1 user,  load average: 2.17, 1.89, 1.77
MP3/OGG archive Total playlength : 8 days, 1 hours, 43 mins 23 seconds
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

attached txn data [WAS: Re: http://bugzilla.gnome.org/show_bug.cgi?id=336843]

Josh Sled
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}`

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment