Errr... sorry, Neil, but you're proposing some quite substantial changes
here, and maybe it's only me, but some of these changes make me feel a
bit uneasy.
In particular, two parts of your proposed multi-part changes seem to me
a bit problematic. And as they IMHO might be quite hard to change once
they have been introduced, I would rather ask whether you can defer
these two parts of your proposed commit to some later time and spent a
bit more time on discussing these. In particular:
1. You propose to pass installations paths by a header file.
2. You propose to separate the configuration option definition from its
documentation.
(And just one nitpicking remark: The auto-generation of a header from a
header.in file is done by "./configure", not by "automake" -- automake
basically only creates a "Makefile.in" from a "Makefile.am", but the
processing of the *.in files is always done by ./configure.)
As for #1, that was:
Neil Williams wrote:
On my system, this header defines (for cashutil):
#define GNC_LIB_DIR "/opt/garfield/cashutil/lib"
#define GNC_XML_DIR "/opt/garfield/cashutil/share/xml/cashutil"
#define GNC_LIB_NAME "libgnc-backend-file.la"
#define GNC_LIB_INIT "gnc_provider_init"
Passing installation paths from one library/application to another by
this method is actually not-so-common or rather "unorthodox". The usual
way of passing such installation paths currently is by pkg-config, where
the library will define variables with the paths in its *.pc file. The
application which wants to access these paths will have some code in its
configure.in script which will retrieve these paths via pkg-config at
./configure time. That code in turn will define C constants which are
either put into the config.h of the application or will directly be used
by passing -D arguments to gcc, but that is totally up to the application.
I must admit that I can't tell the exact reason right now *why* these
paths should better be passed via pkg-config and ./configure (maybe
Derek knows better). But that is pretty much the standard way of passing
such things, whereas defining them as C constants in a header file is
quite non-standard. I would rather prefer to stick with the standard way
and try to avoid to invent a non-standard way of passing such arguments.
GnuCash will need to know where the GNC backend is installed (as it will be
shared with cashutil) and will also pick up the location of QSF via #include
<qof.h>. So GnuCash uses two such header files, gncla-dir.h (which automake
generates from src/backend/gncla-dir.h.in) and qofla-dir.h (from <qof.h>).
In principle that is fine. I'm just a bit confused: GnuCash needs a GNC
backend? Err... can you draw a picture which part depends on which part
here, and where "Gnucash GUI", "GNC backend", QSF, and QOF all fit into
that picture? In particular, which part depends on which one *at compile
time*? That is not a problem, but just a bit confusion on my side.
As for #2:
The configuration options can be modified without recompiling code for a
generic option dialog because once you have the location of the XML file it
can be loaded and used to parse the KvpFrame.
<?xml version="1.0" encoding="UTF-8"?>
<qofconfig xmlns="http://qof.sourceforge.net/"; >
<backend name="GnuCash Backend Version 2">
<option type="gint64" name="file_retention_days" />
<option type="boolean" name="file_compression" />
</backend>
</qofconfig>
This proposal means that the definition of an option will be separated
from its documentation. I think this should rather be avoided. It seems
to me that the translation question (which is totally orthogonal to the
definition and documentation place) distracted you here from a clean
design. I would strongly suggest that *if* you want to define the
options inside the XML file, *then* you should include the description
and tooltip right in that XML definition as well. Otherwise either one
gets forgotten or confused with something else or whatnot. In your
current proposal you would split the definition of one option into
several locations. IMHO this is simply not necessary. You gain much more
code clarity if the definition is contained in one clear location.
That's one of the places where the scheme files were actually a very
nice feature of gnucash.
Note again that the translation question is totally orthogonal to this
definition location. There are several possibilities on how to organize
the translation if a UI-string is inside an XML file, but that would
distract from the definition location here, so I'd explain that another
day. But that's really not complicated. What's much more important is
that the original definition of interfaces is clean and concise, and
from what I gathered these options are precisely a part of the backend
interface.
In summary:
Is it possible to distinguish these two issues from the rest of your
"next commit" proposal? From what I gathered, the rest of your work is
well thought and can be incorporated into gnucash just fine, but these
two issues IMHO really need some more discussion.
Regards,
Christian
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
