On Tuesday 19 July 2005 3:20 pm, David Hampton wrote: > > By the way, we also have the file "acinclude.m4" in CVS. In current > > automake/autoconf versions it is advised *against* that file, so at some > > point in the future we should consider removing that file altogether. > > Agreed. At some point (g2?) we should require current version of all > the autotools, and clean up the code to work properly with them.
That would fit in with the API changes that were discussed in the CLI thread. Whilst CashUtil is presently a separate tree, I have an eye on the changes that would be required to fold it into GnuCash whilst retaining a separate package, in effect making a gnucash-common package that would go alongside QOF. The GUI would add the Gtk interface, the CLI could use the same two libraries without any GUI dependency. CashUtil would be installable with or without gnucash - for those SSH users. We'd have the gnucash GUI frontend, libqof1, gnucash-common and the gnucash-cli frontend - cashutil. CashUtil would depend on QOF and gnucash-common. This would make CashUtil a v.v.small unit - not much more than the shell and a manpage but by working out how to do this separately, it will be easier to move the UI logic into common. 1. Lots of makefile changes to redistribute existing code - e.g. the business objects are needed in the CLI without any gncmodule binding. Updating the autotools would be a pre-requisite for that. 2. Moving existing UI logic into another library, as discussed under the language bindings thread. 3. Remove scheme *entirely* from both of these areas - possibly by defining no-op hooks in the CLI where the GUI currently receives an event etc. Action would then depend on what is linked to the library - scheme or not. This is how the CLI could work with the existing XML backend and SQLite when that arrives. What begins as a query CLI can be the CLI that people have desired for so long. gnucash-common would be a shared library that includes all the current objects - including the business ones - a QOF-enabled GncCommodity (got ideas on that), and the presently ill-defined UI logic that is currently only in the GUI. As I move on with the CLI, I hope to identify precisely which bits of UI are actually necessary for a genuine CLI implementation of GnuCash, growing out of the current CashUtil. Maybe something for GnuCash 2.2? A new branch? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgplhzxrQhdGc.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
