Dear Neil, Am Samstag, 3. September 2005 13:44 schrieb Neil Williams: >> 1. You propose to pass installations paths by a header file. > > OK, it's changed. It's still used for some internal roles (although that > may change). > [...] > The location of the library and the location of the backend config XML file > is now part of the pkg-config and can be retrieved with: > (example only) > MY_LIB_DIR=`$PKG_CONFIG --variable=libdir package` > MY_XML_DIR=`$PKG_CONFIG --variable=xmldir package` > > The name of the library and the name of the init function are expected to > be hard-coded into whichever applications need to use them.
Ok, that's much more "standard-like". Thanks for that. Simple rule of thumb: If it's an installation directory that needs to be passed from one library to another, then pkg-config is the best way to do this currently. One simple reason is this: An application might want to use that directory in other places than C source code. If you pass it by a C header file, you enforce that it can be used by a C source file only. Whereas if you pass it by pkg-config, then ./configure of the application knows it and can use it whereever the application want to -- e.g. by config.h into C source code, or right in the Makefiles, or by a similar config.h-mechanism in other programming languages. Anyway, thanks for adapting that. > > > >> 2. You propose to separate the configuration option definition from > > > >> its documentation. > > > > > > I think Christian's point is that you put the english text in the XML > > > file then load the translations elsewhere. > > I still can't see how this can work. gettext AFAICT won't load the > translations that way. > > All I can see to do is have duplicate strings in the C and XML - I'd rather > not do that. No, surely not -- I don't want anyone to create duplicated strings. Derek was right: I would prefer if the english text of the "description" and "tooltip" is in the XML file, just as the name and type of that option. ... Wait a second. When reading your original description again https://lists.gnucash.org/pipermail/gnucash-devel/2005-September/013608.html you hopefully don't mean that an option already is *defined twice*? From your souce code example I saw that you define an option by writing those lines into your XML file: <option type="gint64" name="file_retention_days" /> but then in your function gnc_file_be_get_config(QofBackend *be) you create the KVP frame which represents the option by adding kvp_values one-by-one. The names are chosen by your #defines, i.e. they are string constants in the C file, and the types are chosen by the respective kvp_frame_set_xy functions. In other words, the creation of your kvp_frame has to manually duplicate the things that are written in the XML file. Did I understand this correctly? That is, errr, probably not so good. Can you please elaborate how you intend to avoid inconsistencies between the XML file and the C source? > If gettext needs the english text in a C file, there seems > little point duplicating it in XML. As for the gettext/translation question: Eventually, translating a string by gettext only means that you pass *one* "const char*" into the gettext() function and you get *another one* "const char*" returned. That's all you need to know. Sorry, I don't have more time now, but I can code up an example how that would look like later. Christian _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
