gnucash/src/register/ledger-core/split-register-layout.c

[Derek Atkins]

linas@linas.org (Linas Vepstas) writes:

> The germans have long yelled at me for this feature, they want to have
> some weird ID numbers as a column in the register.  As long as the code
> is C, and static/compile-time, its hard to add this feature. =20
> 
> -----------
> The need to modify the register in this way was *THE MAIN REASON*
> why scheme was added as an extension language.  However, I think
> we lost sight of this: we wrote lots and lots of scheme code, but
> approximately 0% of it is devoted to making gnucash configurable.
> 
> (changing the color/width/labels on columns doesn't count as=20
> 'configuration'.)

Actually, this is very close to what I mentioned on gnucash-devel
regarding reworking the SplitLedger in general.  A much better
approach would be a configurable table-row where you create a list of
cells-definitions.  Each cell-definition contains:

	label
	widget_type
	get_function
	set_function

Then I can create, eg, a Bank Register by creating a list:

	{ "Date", DATE, xaccTransGetDateEnteredTS, xaccTransSetDateEnteredTS }
	{ "Num", TEXT, xacc... }
	{ "Description", TEXT, ... }
	...

I'd like to extend this to GncEntry, which would look something like
this:

	{ "Date", DATE, gncEntryGetDate, gncEntrySetDate }
	{ "Description", TEXT, gncEntryGetDescription, gncEntrySetDescription }
	...

Obviously this needs a little more work because not all the functions
take the same argument; some will take a Split, some would take a
Transaction (whereas in the GncEntry it is always taking an entry).

Moreover, this doesn't work very well in the case of choices, where
somehow you have to set the possible choices in the cell descriptor.

This means I have three choices:
	a) make the SplitLedger extensible (somehow)
	b) make the SplitLedger know about GncEntry, or
	c) cut-and-paste about 85% of Split-Ledger and make an EntryLedger

I feel that 'a' is the best choice, not only architectually but also
in the amount of time I think it would take to implement.  A
double-win to "do it right".

Actually, as I've been writing about this I've come up with an idea:
use a KVP for the data store and require all objects to have a
Object<->KVP Conversion function.  This makes life a little easier.
The cell-description looks like:

	{
	label
	widget
		{widget definitions}
	data_type
	kvp_slot
	}

The get/set values are all done via the KVP slot and data_type.
Then at the end we get something like:

	xaccTransactionFromKVP (kvp);
or
	gncEntryFromKVP (kvp);
or
	xaccSchedXactionFromKVP (kvp);

Hmm.. I think this might have some promise. :)

Is there a way to list all the kvp slots that exist within a kvp?
That way the various functions can add any non-standard entries to
their own KVP frame.

-derek

-- 
       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@MIT.EDU                        PGP key available