I've managed to enter some guile code from the register: "Transaction > Copy Transaction" will copy the current transaction into an scm object via functions in engine-interface.scm, called from split-register.c, and I presume this scm object is read back to paste later on. Ditto Transaction > Duplicate Transaction.
On Sat, 27 Apr 2019 at 14:29, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > Op zaterdag 27 april 2019 16:05:42 CEST schreef John Ralls: > > > On Apr 26, 2019, at 10:55 PM, Geert Janssens < > geert.gnuc...@kobaltwit.be> > > > wrote:> > > > Op zaterdag 27 april 2019 01:01:38 CEST schreef John Ralls: > > >> What Geert meant is that our current engine code *isn't* particularly > > >> portable, though I think that since it compiles OK on MacOS it > shouldn't > > >> have too much trouble with iOS either. It's a mix of C and C++ and the > > >> main > > >> dependencies are Boost and Gnome Glib; the XML file backend also > depends > > >> on > > >> libxml2 and the SQL backend depends on libdbi. > > >> > > >> The public mirror for our git repository is at > > >> https://github.com/gnucash/gnucash. Note that the stable branch is > > >> "maint". > > >> Doxygen API docs are at https://code.gnucash.org/docs/MAINT. > > >> > > >> Regards, > > >> John Ralls > > > > > > The devil is in the details... The engine code currently still depends > on > > > guile as well, which is a scripting language. Doesn't Apple impose > > > restrictions on that ? > > > I currently don't have a full overview of where guile is used in the > > > engine > > > code. I know the option system is heavily dependent on it, but that's > > > primarily used by the report system. > > > > There's no guile in the backends, and only a little in engine, core > utils, > > and gnc-module for facilitating the wrappers. App-utils is heavy with > > scheme but that's to support application features like options and the > > financial functions for scheduled transactions, and price-quote is > scheme. > > I think John's team can set up a build of just engine and the backends > they > > want to support without swigging and so without guile. That should be > > enough for a companion project similar to GfA. > > > > Regards, > > John Ralls > > I'm glad to hear that. I have a vague recollection of tracing some > transaction > code in the past and ending up in guile. That may have been cleaned up by > now. > > Regards, > > Geert > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
