associate jpeg image of reciept with a transaction?

Derek Atkins warlord at MIT.EDU
Sat Dec 11 10:44:10 EST 2004


This is really fodder for gnucash-devel instead of gnucash-user (as
we're getting way into development issues instead of user issues).
So, I've cc'd both groups.  Followups should go to gnucash-devel.

My personal opinion is that we need to change the way "commit"
processes happen in such a way that we can register callbacks when
things change (or even, are ABOUT to change).  For example, right now
you can specify an account in an invoice line-item and then delete
that account leaving a dangling pointer in the invoice.  Next time you
pop up that invoice -- wham!

If, however, we could register callbacks at pre- and post- commit for
various operations then we could more readily fix this problem.

Why I'm mentioning this now is that your model of "call out to an
external program" fits right into this callback model.  You would
register the callback with "create new transaction" and have that code
then pop up a dialog to ask the user to proceed.  It also makes it
significantly easier to add new operations because you can write the
code and just plug it into the operation stack.

Unfortunately I think this model is probably a lot of work, but I
think it would be a great design.  Anyone want to take this on?

-derek

"Mark H. Wood" <mhwood at ameritech.net> writes:

> To anyone contemplating the addition of such a feature, I'd like to
> suggest that the specific details should not be integrated into Gnucash.
> This feels like an area where lots of people will have lots of different
> ideas.  I would recommend thinking in terms of providing a hook to run an
> external command that passes back a tagged datum which will be stored
> uninterpreted by Gnucash.  When Gnucash activates the "committing
> transaction" hook, something else can e.g. fire up the scanner, then
> either stash the image in a file and hand back a path/URL, or suitably
> encode the image data and pass the whole thing back -- it's just a BLOB
> either way as far as Gnucash is concerned.  (But I'd recommend just a
> pointer to an external document, which document could be used by several
> other programs if need be.)
>
> To make use of the list of additional data attached to a split, it would
> be desirable to be able to augment appropriate menus with callouts to
> one's local handlers, again as external commands.  (It *could* be done
> more cheaply by just adding a generic "additional data" pick to the menus
> whenever a split has additional data, requiring the user to provide his
> own menu gadget if he has defined more than one kind of additional data,
> but that might not save very much coding.)
>
> That should be much easier and quicker to bring into the product, and way
> more flexible.  I imagine that, over time, a sizable package of
> contributed callouts would be built to meet various common needs, and none
> of them should require any further work on Gnucash.
>
> -- 
> Mark H. Wood, radical centrist     OpenPGP ID 876A8B75     mhwood at ameritech.net
> No amount of clipart will save dull writing or an uninteresting topic.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available


More information about the gnucash-user mailing list