translations and option definitions

[Neil Williams]

On Saturday 03 September 2005 11:43 pm, Derek Atkins wrote:
> Quoting Neil Williams <linux at codehelp.co.uk>:
> > I'm working on the code now. If it goes as planned, 

It does work. Here's sample cashutil output:

option name=file_compression
option desc=Compress output files?
option tip =GnuCash can save data files with compression. Enable this option 
to compress your data file.
option value=FALSE
option type=string

option name=file_retention_days
option desc=Number of days to retain old files
option tip =GnuCash keeps backups of old files, this setting dictates how long 
each is kept
option value=0
option type=gint64

Desc and Tip are marked in gnc-backend-file.c using _("") syntax so will be 
translated.

Let me know if those desc/tip strings should be tweaked.

An example of the API for the GUI:

	KvpFrame *backend_config;
	QofBackend *be;

	be = qof_book_get_backend(context->book);
	backend_config = qof_backend_get_config(be);
	if(backend_config) {
		qof_backend_option_foreach(backend_config, 
			print_config_cb, context);
	}

print_config_cb in CashUtil is a test routine:
static void
print_config_cb (QofBackendOption *option, gpointer data);

Then just use a switch for each type of KvpValue and cast from the gpointer.
e.g.
	switch(option->type) {
		case KVP_TYPE_GINT64   : {
			fprintf (stdout, "option value=%" G_GINT64_FORMAT,
				*(gint64*)option->value);
			fprintf (stdout, "\noption type=%s\n", QOF_TYPE_INT64);
			break;
		}

I thought about making 'value' a KvpValue but kvp_value_new_string etc. are 
meant to be private constructors - I reckoned it would be easier to not 
expect the backend and the UI to create temporary KvpValues of their own 
(with or without temporary frames) when a gpointer cast would work instead.

There's not much for the frame to do except keep the option instances 
together, but it does restrict the option->type nicely compared to the 
problems of a GList. Plus the numerical KvpValueType enum is easier and 
quicker to handle via a switch() than the char* QOF_TYPE's are using 
if(0 == safe_strcmp())

(note how I use the QOF_TYPE in the dummy routine as a shortcut to printing 
the type as a string. :-))

> > the XML will be 
> > dropped.

> Ahh... That information had been lost along the way...  Or not stated.

Lost in the depths of an overly long email (again). :-))

Subject: Re: option definition
Date: Sat, 3 Sep 2005 20:13:10 +0100
Message-Id: <200509032013.14665.linux at codehelp.co.uk>
> > Maybe we should ditch the XML altogether and rely only on the KvpFrame and 
> > some API method of determining which keys are present?

> And yes, we probably should have a KVP_TYPE_BOOLEAN.  I don't know why
> we don't.

I'll use a non-translatable string for now, get this commit finally in place, 
get some other CashUtil stuff finished and look at KVP_TYPE_BOOLEAN later. We 
can workaround it in the meantime.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050904/ee4ed24f/attachment.bin