Report wrapper to call python scripts?

[John Ralls]

> On Dec 24, 2014, at 7:38 AM, David Osguthorpe <david.osguthorpe at gmail.com> wrote:
> 
> (By the way note that GnuCash is multithreaded because Gtk is multi-threaded - in the initial
> implementation attempts I had issues with python GIL crashes but these dissappeared when I started
> using proper pygobject based implementations of GnuCashs GTypes).
> 

No, Gtk supports use in a multi-threaded environment, but is not itself multithreaded. In particular, Gtk requires that all calls to Gtk functions occur in a single thread, and on OSX (and perhaps Windows) that thread must be the main thread, the one in which the g_main_loop is executing. Worker threads should use idle events to coordinate with the Gtk thread.

All of the main parts of GnuCash also operate in that one thread. WebKit, however, is multi-threaded. As long as you just hand it HTML and Javascript to render or execute it takes care of everything itself including posting events back to Gtk via the GtkWidget you give it to draw on. That will likely change in the course of the C++11 rewrite, though probably not this development cycle: We first need to have code that's threadable. The current code is too laden with static variables for that to be possible.

I'm frankly amazed that GnuCash's malformed GObjects work with PyGObject considering that they generally ignore GObject's memory management and are directly allocated and freed. Regardless, the C++ rewrite will break all of that because we're removing all GLib dependencies from everything except the GUI. OTOH, since we'll be using C++11 std::shared_ptr and std::unique_ptr for memory management the resulting Python bindings should in the end be a lot more stable than what we have now, although the SWIG folks still have some work to do to fully assimilate C++11 [1].

Another potential problem for your addon: WebKit keeps getting more bloated and harder to build for Windows and OSX; in both cases we're using rather old versions (1.8.3 and 1.6.2 respectively) because of the difficulty of building newer versions on those platforms. We're looking for a lighter-weight replacement. If you're just making HTML strings and handing them to WebKit, no problem, but if you're interacting directly with the WebKitGtk API you'll have to rewrite that as well.

Regards,
John Ralls


[1] http://www.swig.org/Doc3.0/CPlusPlus11.html