On Saturday 03 September 2005 11:43 pm, Derek Atkins wrote: > Quoting Neil Williams <[EMAIL PROTECTED]>: > > 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: <[EMAIL PROTECTED]> > > 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/
pgpe4E4okI74X.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel