[QOF-devel] Outline of new qofevent support

[Derek Atkins]

I have no objection to this API for libqof-1.  Nothing is using this
new API, so might as well do what you suggest and always have the
argument (which can be NULL).  Nothing uses this API at the moment.

My only concern is that this change not require changing the existing
gnucash code...  So for libqof-1 we still have TWO apis, the old-style
and the new-style.

For libqof-2 I'd recommend we switch completely to g_signal and
not even supply a qof_event API; just let the QOF API users use
the g_event API directly.

-derek

Neil Williams <linux at codehelp.co.uk> writes:

> Bearing in mind your earlier comment that gnucash uses so many events, this is 
> actually getting quite complex with THREE types of handlers now supported - 
> two to remain supported into libqof2.
>
> What about if existing calls to gnc_engine_event_gen are mapped (via a define) 
> to qof_event_gen(entity, event_id, NULL) and calls directly to qof_event_gen 
> can choose to use or not to use an argument?
>
> Redefine qof_event_gen(entity, event_id, event_data)
> where event_data is a gpointer and can be NULL.
>
> Then we'd have just one typedef, one handler in libqof2 and I can pass an 
> event argument in all cases - it'll just be NULL sometimes.
>
> Existing code would use old style handlers that do not support event data, new 
> handlers would use the new code and have a choice about whether to use event 
> data or not.
>
> As 0.6.2 is not released yet, the qof_event_* syntax is not yet part of the 
> API so it can be changed, leaving gnc_engine_event_* as the deprecated old 
> style.

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available