Longer term projects

[Phil Longstaff]

Have you given any thought to what it will take to replace qof event notifications with gobject signals?  The models are substantially different.  With qof, you register for all events and get everything, and then need to weed out what you are interested in, based on event type and object type.  To receive gobject signals, you need to connect to the signal for specific instances.

For some things, e.g. new prices, we could use the pricedb as the object which emits the signals when new prices are added or prices are modified.  How about for new engine objects?  do we need a gnc_engine object for these signals? 


________________________________
 From: John Ralls <jralls at ceridwen.us>
To: Phil Longstaff <phil.longstaff at yahoo.ca> 
Cc: GnuCash development list <gnucash-devel at gnucash.org> 
Sent: Thursday, January 12, 2012 10:33:41 AM
Subject: Re: Longer term projects
 

On Jan 12, 2012, at 5:51 AM, Phil Longstaff wrote:

> There are a number of longer term projects, among them Gtk3 and engine cleanup.  I've been distracted by other matters but can now devote some time to Gnucash.  From what I can tell, John Ralls has been pushing the engine work (unit testing, converting to real gobjects).  Geert (I think) has been converting to GtkBuilder which I assume is part of the gtk3 work.  Where would I be most useful?  I do have a few specific itches to scratch, mostly around budgetting, but want to help with the infrastructure changes as well.


Super!

My bias is toward getting as much as possible under good test coverage (both unit test and "integration" or "acceptance" tests), rewriting into a good object-oriented design using the GObject framework, and improving the MVC separation. From that POV:

You could scratch your budgeting itch by writing unit tests for the budgeting code, then working it over to make sure that it fully uses Glib and GObject and has good MVC separation.

Or unit testing and GObject-ifying the sql/dbi backends, or the xml backend, or you could pick up where Muslim left off in libqof -- especially getting rid of the parts like QofObject and QofEvent which duplicate (badly) GObject facilities.


Regards,
John Ralls